> 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 mind. 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.
