[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