Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Gunnar Morling gunnar at
Wed Sep 28 09:37:20 UTC 2016

>  If I'm compiling a class A that has a reference to a member in type B
> then do you really want the compiler calling into a security manager to
> ask if this access is allowed?

I don't think that is what those folks asking about using the SM had in

Rather, the idea would be - IIUC - to grant code in module B (say an ORM
tool) reflective access to non-exported (and of course exported) types in
module A (say a module with entities) by default. If needed, the code in B
would then use setAccessible() for making private members in A accessible
before invoking them, allowing it to obtain the entity state. This is where
the SM is part of the picture: if in a given environment the user wants to
restrict who may call setAccessible(), they could use the SM for it, with a
fine grained policy, e.g. allowing the call only to the ORM module.

I.e. ReflectiveAccessToNonExportedTypes would be granted by default, only
if an SM is enabled at runtime, actions to suppress accessibility checks
would be subject to the current security policy.

This is not to say that I'm behind this idea, I just felt it hasn't been
discussed in the way it may have been meant.

I can see though how JDK devs and library authors want to prevent access to
private code in their modules at all, hence relying on the SM to be enabled
at runtime is not an option to address that requirement.

More information about the jigsaw-dev mailing list