JPMS Access Checks, Verification and the Security Manager

[Alex Buckley]

On 5/24/2017 12:13 AM, Volker Simonis wrote:
> OK, so from what you say I understand that the verification errors I
> see with the Security Manager enabled are an implementation detail of
> HotSpot (because verification uses the same class loading mechanism
> like the runtime) which is not required but still acceptable under the
> JVMS. Is that correct?

The JVMS is precise about which exceptions are allowed to be thrown by a 
JVM implementation during verification, and AccessControlException is 
not one of them. However, the JVMS is only one part of the Java SE 
Platform Specification. It is quite proper if another part specifies an 
AccessControlException when a class in a restricted package is 
referenced by a class without permission.

I'm thinking in particular of the API specification for 
SecurityManager::checkPackageAccess. It states, "This method is called 
by the loadClass method of class loaders." Plainly, the intention is 
that a class (Tricky) which initiates the loading of another class 
(com.sun.crypto.provider.SunJCE) can do so only if it has permission to 
reference the other class. Unfortunately, the statement as written is 
only guaranteed to be true for the built-in class loaders of the Java SE 
Platform and not for user-defined class loaders. Accordingly, we will 
update the API specification to clarify how a JVM implementation may 
support the Security Manager in checking permissions when classes are 
loaded and resolved. But to answer your original question, an 
application CAN fail because the verifier can't load classes due to 
Security Manager restrictions; you may have to grant additional 
permissions if application classes wish to reference certain JDK 9 packages.

Alex