On Tue, May 23, 2017 at 10:20 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > Volker - one suggestion for your experiments is to change your JDK 8 > security properties file (java.security) to add "com.sun.crypto.provider." > to the value of the "package.access" property. That should mean you will get > the same AccessControlException with JDK 8 as you do with JDK 9. It may help > to reason about the JDK 8 behavior, including what is triggered by > verification, before looking at 9. >
You're right. JDK 8 produces the same error if we add "com.sun.crypto.provider." to the value of the "package.access" property. I didn't wanted to blame jdk9 here - I just saw this difference because "com.sun.crypto.provider." isn't contained in the "package.access" property by default. So maybe I rephrase my question a little more generally: Is it required for the verifier to do security and/or access checks during the verification phase or could/should these checks be postponed to runtime? The issue with verification errors due to missing classes from Remi's previous answer is probably a corner case of this question. The other question is if '--add-exports' should implicitly grant the corresponding security permissions? I understand that package/class visibility and security checks are somewhat orthogonal concepts so I tend to agree with the current functionality (and a part of this problem is now tracked by JDK-8174766). Nevertheless it is probably wise to document these differences so people won't get surprised. > On the "Error: A JNI error has occurred, please check your installation and > try again" message. It's not core to your questions of course but I agree it > is confusing. Ramanand Patil had a number of attempts on core-libs-dev to > improve this and it may be that more is needed there. > Yes, a better error message would be nice but thats a different question. Thanks, Volker > -Alan >
