On 5/23/17 10:44 AM, Volker Simonis wrote:
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.
We considered it but the SecurityManager checks all callers (and not
just the target module) on the stack for the appropriate
accessClassInPackage RuntimePermission. Also,
SecurityManager.checkPackageAccess does not know what the target module
is, all it has is the package name. It is possible however that we could
respect the module access rights when loading classes in the internal
ClassLoader.checkPackageAccess method. I will be looking more into this
in the JDK 10 timeframe.
The current javadoc of SecurityManager.checkPackageAccess [1] does
document this behavior:
"This implementation also restricts all non-exported packages of modules
loaded by the platform class loader or its ancestors. A "non-exported
package" refers to a package that is not exported to all modules.
Specifically, it refers to a package that either is not exported at all
by its containing module or is exported in a qualified fashion by its
containing module."
--Sean
[1]
http://download.java.net/java/jdk9/docs/api/java/lang/SecurityManager.html#checkPackageAccess-java.lang.String-
