[jsr294-modularity-eg] 'requires local ...' must be constrained

Richard S. Hall heavy at sun.com
Fri Feb 6 22:25:38 EST 2009


 From my perspective, a "require local" concept has no place in the 
language, since it seems to be a run-time concept.

It seems we are confusing language-level modularity with a module system.

-> richard

Bryan Atsatt wrote:
> If we allow M1 to require M2 to be 'local' (same loader), then M1 can 
> trivially access M2's package-private members:
>
> module M1 at 1.0 {
>   requires local M2;
> }
> module M1;
> package secret.stuff;
> public class KeyAccessor {
>     public String getSecretKey() {
>         return Key.getMySecretKey();
>     }
> }
>
> module M2;
> package secret.stuff;
> public class Key {
>     static String getMySecretKey(){...}
> }
>
> We must not allow this by default; instead, a module should be able to 
> declare what other module(s), if any, may make it local, e.g.:
>
> module M2 at 1.0 {
>
>   permits local M3;
> }
> which would cause M1 to fail. Without the permission, no module may 
> make another local; this is exactly analogous to constraining 
> importers ('requirers'? :^), but with the inverse default.
>
> // Bryan
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg


More information about the jsr294-modularity-eg mailing list