Thanks Alex, that makes sense.
Regards, Volker On Fri, Jun 2, 2017 at 2:13 AM, Alex Buckley <alex.buck...@oracle.com> wrote: > 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
