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