-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Artificial OpenJDK Restrictions - Versions 1.13/1.14/1.15/1.16 (but not 1.11.2 or 1.12.2) #7829
Comments
Add the JVM argument (before |
Those versions are unmaintained and we have no interest going back to patch them, you can already disable the checks on most versions of those releases |
Thanks. I did not know about this flag. That completely solves my problem! I understand the patching situation completely and that these aren't maintained. People want to run them anyways and this should take care of the issue, I wish I'd asked sooner! |
worth noting that some versions actively break with newer java versions |
That certainly is worth noting. Any ideas which ones they are? I didn't have the person that filed the issue about this complain but they probably aren't running the exact ones you're talking about. I feel like running older versions isn't just not unusual at all, it's probably the norm for larger multiplayer servers. All of the biggest ones are on ancient Minecraft versions. Do any of these projects support this? A lot of them used to run Paper but I doubt that's true now. It can't be. Unless big servers get special support I'm guessing they've moved on and I'd like to know where they moved on to as that's probably the place to be (it's how I got here but I feel like I've been left behind). This is all 100% well within the developer's rights. I still think Paper is among the best. I wonder though what these big server admins are running now though. Like is my conspiracy theory that big servers do get support right? Is that why 1.12.2 works? My guess would be that the real answer to this question is yes. Old versions are supported IF you are important enough. Probably not a coincidence at all that 1.12.2 has been silently fixed and they haven't bothered with the versions newer than that (1.12.2 is what legendary servers like 2b2t run which I'm sure you're well aware). I bet you guys will though when/if the big boys start moving up in versions. You should have just said that if that is the case. It's not even wrong. Those are the people who have the resources so it makes sense. It makes you guys look like idiots who have no clue what they're doing while the truth makes you guys look like the competent and capable team that I know you are. The truth also gives me options: most importantly time. If these will be fixed eventually if bigger servers move to those versions that would be incredibly valuable and useful information. |
not on top of my head. generally you notice it quickly fast if it breaks (mostly netty, so server will not even start), so not really something to worry about.
bigger servers are expected to run their own forks, in order to apply important security fixes themselves.
paper doesn't provide any special support, all our code is in this repo. I think there are a handful more or less good forks for older versions, but nothing we can endorce. as I said, big servers just write the code themselves.
only once in the last years is that we have ever pushed code to older versions, that was for log4j, because we felt like that exploit was so dangerous, not only the minecraft server, but the actual server and everything on the network, and to an extend, the whole internet. we have no interest in supporting older versions, the code and tooling gets much nicer on latest, so its just not fun (this is a hobby for all of us), plus its also not sustainable. paper is a big project and even bigger ambitions, we can't split our workforce between multiple versions. we only do so in the transition time while we wait till our users updated to the new mc version (as indicated by our stats)
I really don't understand your general vibe. you seem like upset with us, either for adding the check (which we haven't, that was a change done by upstream, we just added the super useful flag to disable the check ;) ) or for supporting old versions (especially after reading the ticket on your repo) I hope this gives some insight in how I, as one of the idiots that is leading this project, sees this stuff, and how the community generally sees this. if you have any more questions, don't hesitate to ask here or on discord. edit: decided to waste more time on this since I didn't understand your point about 1.12.2 being silently fixed. turns out, the check was added by upstream for the 1.13 update, so it was never there in 1.12 and we sure as heck didn't "fix" it at any point down the road. |
This is really good. I want to say thank you for doing this right off the bat. That's fantastic.
So I was more upset by some of the answers here mostly because I know that it isn't true that there's "no support" for older versions. It's complicated. The complicated stuff though is why I'm here. People are asking me in projects I'm responsible for why certain ones of these aren't working. That is my interest. It is frustrating when people are either being coy with or think I'm too stupid to understand the real situation but that is actually exactly why I'm here and what I'm trying to find out.
You're right, and this isn't an easy question. I generally try to support what my users are doing and this is the same problem you have. I'd probably try to do exactly what you guys are doing under the circumstances with maybe a few additional tweaks but honestly not many. I commend that you patched the log4j out anyway even though these old versions aren't generally supported. The only tweak I would make is to maybe clean up some of the Java compatibility but I understand that is one hell of a rabbit hole and I do know what that is asking
I don't think you are idiots. I even said in that exact sentence that I know you guys are competent and capable developers. I've had interactions with the Paper team before but my favorite person (Aikar, someone who has inspired me going back a lot of years with projects like his "Timings" tool) doesn't seem to be very active right now. The situation is much more complex than the original answers I received:
That's not true though. You guys aren't giving yourselves the credit you deserve here! You guys do care and patch the worst of the worst like log4j. That's very important to me and a lot of users. If I were to ask you to consider anything it would be to put allowing modern versions of Java to run in this camp for basically the same reason as log4j. Some sort of "supercritical fixes" category but then tell people for anything else like bugs or whatever that it's not on the table for those. It has to be some kind of critical security issue which I'd argue running something like OpenJDK 13 most certainly is and will only become more so over time. No one would expect this to be done right away even if the decision was made. The versions that aren't working seem to not be working because not that many people try to run some of those middle versions between 1.12.2ish and just going straight to modern/current. I understand that these Java compatibility issues are almost certainly rabbit holes. There's no hard feelings here on my part toward anyone. I learned a lot from our conversation including your post. I didn't know some of this stuff despite having used Paper downstream in my projects for years. I really don't think we're that far apart on this stuff and yes I painted it in the absolute worst light to make my points but I hope I at least clarified where I am coming from here a bit. |
I actually did consider removing the java version restrictions on older versions when doing the log4j backports but decided not to after bringing it up. There was already enough debate about whether older versions should be updated for log4j in the first place and it wasn't really necessary to add that into this mix. It didn't seem very important, and if anything, it'd just be converting it to a warning (which the added system property does). The java version check originated from 1.13 with the removal of item ids/the rest of the flattening. With this, in order to maintain legacy compatibility with older plugins, spigot uses asm to rewrite certain parts of plugins on load to still be compatible. This is (primarily) what breaks on newer java versions. After updating for log4j it was pretty much definitively decided that older versions will not ever get an update again, and if something like log4j does happen again they will either just be removed, or even stronger warnings added to the downloads page. I understand the frustration with this check and it is limiting to these versions, but it for sure won't be removed on them at this point. For 1.18, it was actually fully removed though. so no need to use |
my message wasn't meant to impl that, I like to call myself an idiot, lol
yeah hes pretty busy with real life stuff and only really available behind the scenes.
as you can imagine, you aren't the first to ask such questions and we try to be efficient with our time, so we keep answers short (most people don't care about all the history we went thru in the last 12 years).
it is just not sustainable. java releases twice a year. so does minecraft. we already have 10 legacy versions, so we get 2 more per year. you can quickly see how the work needed to verify that those versions work properly on the newest java version scales exponentially. and if it breaks, we can't just fix it, most of the code isn't written by us, its written by spigot, by bukkit, by mojang. changing stuff is always hard cause of the possible side effects. its also just not worth it, you can see that right now, 75+% of servers use 1.17+ https://bstats.org/global/bukkit#minecraftVersion
no hard feeling here either, glad I could clear things up. |
What?! Okay, maybe I didn't know what I was asking. That is intense. I know what that means. So we are talking 1.13-1.17 here specifically. That alone helps. Fortunately I feel like not a lot of people try to run those specific versions (I hate making statements like this but generally speaking not many people are clammoring to run 1.16). This helps a lot to understand why (more than I thought it would). I think this can be worked with. If people really need to run older versions I can tell them definitely 1.12.2 or I believe 1.11.X or whichever revision that one ended on is what they should use. I will even be able to give them a reason (the flattening / itemids being removed and the difficulty/complexity of dealing with this). I have the flag set on the project now to help people try to run these versions where it will / does work for whatever reason. The OpenJDK revisions are an absolute nightmare and have been for my projects for years. These days I'm trying to use the Adoptium OpenJDK with it rather than relying on or replacing the built-in system OpenJDK. I'm using 17 at the moment but I heard a couple of weeks ago that Paper can now take OpenJDK 18 and it sounds like the checks are gone altogether now anyway (in 1.18). An example of this is my new Paper Minecraft Java Docker container here: https://github.com/TheRemote/Legendary-Java-Minecraft-Paper although I also do this in my older project and my standalone project that has been around a lot longer here: https://github.com/TheRemote/RaspberryPiMinecraft They also have a workaround option that they can just download a binary of an older OpenJDK and it's stored in a "jre" folder so there are ways to deal with this without compromising the system's java. It's just more complicated to set up independent OpenJDK versions but in some of these cases they will have to (or maybe the better way to say this is I will have to in the case of downstream projects if this is something that starts coming up more than this one time and people really want it). I'll be able to help them now though that I have a better understanding of what exactly the problem is and why (and which versions to watch out for this on). Thank you everyone! |
I definitely wondered if you meant it like this but I definitely didn't want that to be one of our misunderstandings for sure. I definitely do the same thing!
Oh yeah, definitely. I get a tiny, tiny fraction of what you guys get. I did try to look for some of this stuff but even searching the GitHub issues in this repo is overwhelming. I have no doubt it came up over although some of the variations of my questions were a lot more difficult to search for (most regular users not doing development work describe this stuff... differently let's say).
For sure. That is understandable. You guys have debunked my conspiracy theory that large servers get special support on older versions and that this is actually a technical problem. In fact I'd wager the reason they are on 1.12.2 on a lot of the larger servers is this exact reason. They have the same problem taking their forks higher. It's going to be nasty, grueling work. It might be easier to skip all of those middle versions straight to 1.18 but you guys would have to tell me on that one (it just seems like it from what you're describing, that may basically mean starting over or starting from something else that has already been rebased).
Absolutely. There has to be a line somewhere or you won't be able to use your resources effectively. I think this range of versions (roughly 1.13-1.17 let's say) makes sense. It can also be worked around. If people need to run older versions then 1.12.2 is probably where it's at. If they need to run one of those specific middle versions they will probably need to download a standalone JRE that is that older version for compatibility reasons. Thank you for the answers / discussion! |
Stack trace
Plugin and Datapack List
None
Actions to reproduce (if known)
Use an OpenJDK newer than 13
Paper version
Versions 1.13/1.14/1.15/1.16 (but not 1.11.2 or 1.12.2)
Other
TheRemote/RaspberryPiMinecraft#39
Hello,
I'd like to request removal of the restrictions that do not allow OpenJDK versions higher than 13 to run the middle versions of Paper. 1.11 and 1.12 do not have these restrictions and they run fine.
Forcing people to run these ancient OpenJDK versions that are like 5 series out of date is a security problem and there is no reason for it. Some of these Minecraft versions aren't even that old especially compared to 1.11 and 1.12, now THAT is old and it works just fine.
I assume this is just an artifact/oversight that these are still left in place. Obviously if 1.11.2 and 1.12.2 will run on OpenJDK 17 there isn't going to be a problem (nor should there be). They wouldn't have known that at the time though. Thanks!
The text was updated successfully, but these errors were encountered: