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

[Bryan Atsatt]

I understand your sentiment, but... The line between language and 
runtime is already blurred here: package-private access is defined in 
terms of class loaders (as I'm sure you know). And I can't tell you how 
many times I've had to explain this to developers who are tearing their 
hair out over an IllegalAccessError with package-private.

With permit/require local, the compiler can (finally) reason about  
package-private access, and provide meaningful errors early in the dev 
cycle, where they belong.

// Bryan

Richard S. Hall wrote:
> 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
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>