Module accessibility

[David M. Lloyd]

On 12/22/2011 05:03 AM, Jesse Glick wrote:
> They would still work, but you may want to ban outside access to
> implementation packages despite their containing public members. For
> this case also, an explicit list of "exports" clauses would work if
> recompiling with -source 8 or using 'jar uvf *.jar module-info.class'.

Just a quick note on this - it's not really clear what banning outside 
access would entail here.  Normal accessibility rules would be a 
sufficient check at compile-time for sure.  But at run-time, if you have 
a module's class loader, unless you use slow/clunky/possibly error-prone 
call stack introspection on every class load request you can't really 
enforce this visibility constraint.  So pretty much all you can do to 
enforce this rule is:

1. Only link exported paths (which is already the case, for us at least)
2. Prevent unauthorized access to a module's class loader (via 
Permission) when a security manager is present (we use a general 
RuntimePermission for all modules but I think for the JDK usage we 
could/should be more fine-grained)

I view module ClassLoader access as analogous to having a 
java.lang.reflect.Method which has its "accessible" attribute set to 
true.  Basically anyone who has the reference the the ClassLoader has 
full access to the module.  So yeah this means that any non-public class 
in a public and imported package can be *loaded* by, say, 
Class.forName("org.blah.Name",false,moduleClassLoader) but the normal 
accessibility checks would apply.

The alternative is to add more run-time checks; the performance penalty 
could be substantial.
-- 
- DML