I've long been a fan of NetBeans' module system and of OSGi so Java 9's modules are a big improvement to me.
Except modules are really good at enforcing API boundaries and stop allowing one to freely use any public class.
An error such as this is no fun:
I've assumed that this has to be tweaked at SecurityManager level and played with -Djava.security.manager and -Djava.security.policy and the very handy -Djava.security.debug.
Alas, that doesn't help. (Although I'm still convinced it should, unless there is a bug somewhere).
What one needs to use is the magical -XaddExports flag. This forces an export and allows the code to run:
Except modules are really good at enforcing API boundaries and stop allowing one to freely use any public class.
An error such as this is no fun:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class A$1 (in unnamed module @0x3fb6a447) cannot access class jdk.nashorn.internal.ir.visitor.NodeVisitor (in module jdk.scripting.nashorn) because module jdk.scripting.nashorn does not export jdk.nashorn.internal.ir.visitor to unnamed module @0x3fb6a447
I've assumed that this has to be tweaked at SecurityManager level and played with -Djava.security.manager and -Djava.security.policy and the very handy -Djava.security.debug.
Alas, that doesn't help. (Although I'm still convinced it should, unless there is a bug somewhere).
What one needs to use is the magical -XaddExports flag. This forces an export and allows the code to run:
java -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.parser=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime.options=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir.visitor=ALL-UNNAMED A
No comments:
Post a Comment