Module accessibility

Jesse Glick jesse.glick at oracle.com
Thu Dec 22 09:11:52 PST 2011


On 12/22/2011 11:07 AM, David M. Lloyd wrote:
> at run-time, if you have a module's class loader [...] you
> can't really enforce this visibility constraint.

The class in the unexported package might be visible, but the Jigsaw-enhanced VM would ensure that it is not accessible. Just as with reflection generally, Class.forName 
might return a Class yet Class.newInstance (for example) would fail with an IllegalAccessException. This is in contrast to existing module systems without VM support, 
where you might not be able to link statically against a class in an unexported package, but you could still call it reflectively without special permissions.

> I view module ClassLoader access as analogous to having a java.lang.reflect.Method which has its "accessible" attribute set to true.

Again this is a description of current module systems built on older JVMs and only able to control visibility by overriding ClassLoader.loadClass to throw 
ClassNotFoundException even when a parent loader can load the class. As I understand it, Jigsaw would enforce the same accessibility on reflective calls as in the 
compiler and linker.



More information about the jigsaw-dev mailing list