[Java 16] .. module java.base does not "opens java.lang" to unnamed module @7907b4c9

[mrfloris]

With java16 out now I thought it would be time for me to move on from java11 in anticipation for java17.

Running the server went well, minus two plugins. One being aswe. I thought i'd share my findings.

[08:50:08 ERROR]: Could not load 'plugins/AsyncWorldEdit-3.8.2.jar' in folder 'plugins'
org.bukkit.plugin.InvalidPluginException: java.lang.ExceptionInInitializerError
    at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:141) ~[patched_1.16.5.jar:git-Paper-592]
    at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:397) ~[patched_1.16.5.jar:git-Paper-592]
    at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:305) ~[patched_1.16.5.jar:git-Paper-592]
    at org.bukkit.craftbukkit.v1_16_R3.CraftServer.loadPlugins(CraftServer.java:389) ~[patched_1.16.5.jar:git-Paper-592]
    at net.minecraft.server.v1_16_R3.DedicatedServer.init(DedicatedServer.java:251) ~[patched_1.16.5.jar:git-Paper-592]
    at net.minecraft.server.v1_16_R3.MinecraftServer.w(MinecraftServer.java:1055) ~[patched_1.16.5.jar:git-Paper-592]
    at net.minecraft.server.v1_16_R3.MinecraftServer.lambda$a$0(MinecraftServer.java:289) ~[patched_1.16.5.jar:git-Paper-592]
    at java.lang.Thread.run(Thread.java:831) [?:?]
Caused by: java.lang.ExceptionInInitializerError
    at java.lang.Class.forName0(Native Method) ~[?:?]
    at java.lang.Class.forName(Class.java:466) ~[?:?]
    at org.bukkit.plugin.java.PluginClassLoader.<init>(PluginClassLoader.java:79) ~[patched_1.16.5.jar:git-Paper-592]
    at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:137) ~[patched_1.16.5.jar:git-Paper-592]
    ... 7 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module java.base does not "opens java.lang" to unnamed module @7907b4c9
    at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357) ~[?:?]
    at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) ~[?:?]
    at java.lang.reflect.Method.checkCanSetAccessible(Method.java:199) ~[?:?]
    at java.lang.reflect.Method.setAccessible(Method.java:193) ~[?:?]
    at org.primesoft.asyncworldedit.utils.Reflection.invoke(Reflection.java:119) ~[?:?]
    at org.primesoft.asyncworldedit.Loader.findLoadedClass(Loader.java:251) ~[?:?]
    at org.primesoft.asyncworldedit.Loader.loadClass(Loader.java:173) ~[?:?]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:519) ~[?:?]
    at org.primesoft.asyncworldedit.AsyncWorldEditBukkit.createInjector(AsyncWorldEditBukkit.java:336) ~[?:?]
    at org.primesoft.asyncworldedit.AsyncWorldEditBukkit.inject(AsyncWorldEditBukkit.java:226) ~[?:?]
    at org.primesoft.asyncworldedit.AsyncWorldEditBukkit.<clinit>(AsyncWorldEditBukkit.java:94) ~[?:?]
    at java.lang.Class.forName0(Native Method) ~[?:?]
    at java.lang.Class.forName(Class.java:466) ~[?:?]
    at org.bukkit.plugin.java.PluginClassLoader.<init>(PluginClassLoader.java:79) ~[patched_1.16.5.jar:git-Paper-592]
    at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:137) ~[patched_1.16.5.jar:git-Paper-592]
    ... 7 more

Using https://adoptopenjdk.net/ > openjdk 16 (latest) / HotSpot with Paper version git-Paper-592 (MC: 1.16.5) (Implementing API version 1.16.5-R0.1-SNAPSHOT) and WE WorldEdit version 7.3.0-SNAPSHOT+5758-504b8bb

I hope this information is enough for aswe to make the first updates to support java16.

[SBPrime]

Well thats what you get for being the early adopter.

The plugin works fine with java up to 1.15, when I tried to run spigot with 1.16 it complained that 1.16 is not supported :)

Never the less this should help you: https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m/41265267#41265267

# --add-opens has the following syntax: {A}/{package}={B}
java --add-opens java.base/java.lang=ALL-UNNAMED

OR

--permit-illegal-access

I managed to run the plugin by adding those options to the command line: --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.security=ALL-UNNAMED

[mrfloris]

"Well thats what you get for being the early adopter."

Yeah, so, be glad that someone is even bothering to report back to you?

No need to give some sort of attitude or be judgy as to how others run their servers/systems. Especially when we tested with over 100+ plugins and had an issue with Multiverse-Core because we were a few versions behind, and this is literally the only other plugin with an error. I could have just been "f this outdated crap that doesn't get updated, let's switch to FAWE and be done with it". Instead I bother to share the experience so you are aware and perhaps can stay current.

Java 1.15 ? I will assume you mean java 8 , java 15, java 16.

Everybody tells us in the Tuinity, Paper and Spigot community to use https://adoptopenjdk.net/ where for these OS the options are not 15, it's 8, 11, 16. We've been on 11lts for years, and in anticipation we're moving to 16. The version everybody is lately recommending.

Yes, it's worth a test, we tested, and found one issue, reporting it back - and then "ThATs WuT yOu GEt"

As a server owner we can never win. If we're on 8, we get judged by paper for not being on 11, if we say to devs we're on 11, they point at us for being outdated and not even being on 16. We move to 16, we get told by you it should be 15.

java 8 is end of life, java11 is lts, but ready to be replaced by java17

These type of illegal reflection warnings have been generating since java 11, and we've reported them before. To quote someone: "Plugin devs had loads of notice that they had to fix their sh#t"

java 15 is just a short-term release, only to be supported with Oracle Premier Support for six months until JDK 16 arrives last March, it's April.

https://www.oracle.com/java/technologies/java-se-support-roadmap.html#:~:text=For%20product%20releases%20after%20Java,11%20is%20an%20LTS%20release.

I am not being unrealistic here. And going with the premium awe, I did not think it was out of scope to report back to help a premium plugin to stay current ~ because I am not the only one on java 16.

Thank you for looking into running it with java16 and giving a temporary solution to run it still. Will clone the live server and do some further testing. Sorry for not reporting any further issues moving forward. Early adopters shouldn't bug report, lesson learned.

[SBPrime]

I’m sorry if you feel like that, by the comment about early adopter I literally was fulling around, and it was a joke. In the industry that I work, using something that is not at least couple of years old and proven in battle is considered “early adoption” ;). That aside I and many developers that I work professionally (I’m not some script kiddy, I have over 20 years working as a developer) with don’t agree with the approach java is going with the reflection.

I assume that you don’t know how the plugin works internally, and I don’t blame you nor do I expect that from you. But to make it work as it is now some parts of the “illegal” reflections are necessary. The plugin is not a fork of WorldEdit it works on top of it by hooking into the API and overriding parts of WE.

For the plugin to work there are 4 options:

• fork WorldEdit and include its code inside AsyncWorldEdit - although this solution sounds lucrative it means you will always be behind WorldEdit in terms of updates,
• override WorldEdit code at runtime and use some reflection to plug it in - this is the current approach, and it has proven to be bullet proof for years,
• rewrite the plugin to inject changes to WorldEdit code offline (or at boot) - this option is one of the routes moving forward, although I received complains from spigot that they might ban this, in addition this solution will be unstable
• rewrite the plugin to be an java agent - this option is one of the routes moving forward, again I received information from spigot that it might not be inline with their guidelines/requirements, in addition this solution will require ALL server admins to change the scripts they use for starting the server. Never the less this is the best solution for me, because it opens a lot of opportunities and will allow me to simplify the plugin.

I hope that you understand my position, and why I’m reluctant to change how the plugin works internally. I made couple of decisions back when the plugin was created, and for the moment I stand by them.

I wish you the best.

[JJBRT]

It can be solved without any JVM parameter with Burningwave Core reflection components that thanks to a special driver work on all JDKs from 8. In this case you can also simply call the method org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll()