Closed mrfloris closed 3 years ago
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
"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.
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.
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:
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.
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()
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.
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 WEWorldEdit version 7.3.0-SNAPSHOT+5758-504b8bb
I hope this information is enough for aswe to make the first updates to support java16.