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
