Hi Nikolai,
On 05/19/2017 12:41 PM, Nicolai Parlog wrote:
Hi!
I'm too lazy to try right now
It's easy. Take this example:
public class Test {
public static void main(String[] args) throws Exception {
Object theUnsafe = Class.forName("jdk.internal.misc.Unsafe")
.getMethod("getUnsafe")
.invoke(null);
}
}
Running this on classpath without any additional JVM options produces:
Exception in thread "main" java.lang.IllegalAccessException: class Test
cannot access class jdk.internal.misc.Unsafe (in module java.base)
because module java.base does not export jdk.internal.misc to unnamed
module @63d4e2ba
at
java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:445)
at
java.base/jdk.internal.reflect.Reflection.throwIllegalAccessException(Reflection.java:436)
at
java.base/jdk.internal.reflect.Reflection.ensureMemberAccess(Reflection.java:112)
at
java.base/java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:407)
at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:399)
at java.base/java.lang.reflect.Method.invoke(Method.java:535)
at Test.main(Test.java:9)
(note that the exception is thrown from Method.invoke)
When run with:
--add-exports java.base/jdk.internal.misc=ALL-UNNAMED
...the example works (does not throw exception), but when run with:
--add-opens java.base/jdk.internal.misc=ALL-UNNAMED
...the example still works!!!! OOOPS - this is a bug!!! This is
definitely a bug.
If --illegal-access=permit is an alias for opening all modules to
ALL-UNNAMED, then we definitely have a problem as above example can be
successfully executed even with SecurityManager enabled!!!
Regards, Peter
but I'm pretty sure I repeatedly observed
the behavior Volker describes:
A module depends on an internal type and is compiled successfully
thanks to --add-exports. At run time it would fail without flags and
would work with --add-exports but it also works with --add-opens.
so long ... Nicolai
On 19.05.2017 12:24, Peter Levart wrote:
Hi Volker,
On 05/19/2017 11:48 AM, Volker Simonis wrote:
From my understanding, at run-time, "open" implicates "exports"
(i.e. if a module M1 opens a package P for some other module M2
it also, implicitly exports P to M2). The "big kill switch" in
both, its old and in the newly proposed form, usually only refers
to "enabling reflective access" but doesn't explicitly mentions
that it will also, implicitly export the respective packages.
Also, the usage of the "kill switch" only produces warnings for
reflective accesses which are enabled by the option itself (and
not at the same time, explicitly allowed by --add-opens
directives). But it doesn't warn about the simple, non-reflective
accesses to packages which are implicitly exported by the kill
switch as well.
No, you got it wrong. "opens" is just a backdoor for reflection
(and MethodHandles.Lookup). It does not implicitly also mean
"exports". Neither in compile-time nor in run-time. Otherwise
everything that is declared "public" would be accessible to
reflection without the need for .setAccessible(true) - therefore
even to code running with SecurityManager enabled!
Regards, Peter
