Updating Java to JDK 21 (Latest LTS JDK)
Opened this issue · 3 comments
Background
Why are we using Java 8? The reason is that it is the "latest" version of Oracle Java on java.com. It is commercially common and the mostly-used version along the time and the history. As since JDK 9, JDK later than 8 are no longer really fully compatible with Java 8 and below. This causes an issue to the old businesses.1
Originally, Minicraft is written in the version earlier than Java 8 since it was before the release of Java 8, 2014. However, because of the forementioned reasons and background, it is now still sticking with Java 8.2
Another reason that holds is that java.com, the delegate and most famous website holding Java, is still holding Java 8. Since people would likely to follow the website, it is kept on Java 8. However, it seems like this is barely just the reason.3
Reasons to Upgrading
There are several concerns that Java 8 is already outdated and the later versions are more modern, advanced, secured and efficient in development.4 It is not always the case that later versions can be compatible with older versions, so it is quite problematic to use different versions of JDK apart from using always Java 8 for 1.8 and below.5 It is quite common to see websites suggesting to use more modern JDK versions for nowadays development.67 More than that, modern JDK versions also introduced quite a number of features helping development, like modules, keywords, etc. It is quite obvious that Java 8 is no longer maintained, including some minor bugs, that also appeared in this project.8 It is possible that no more bugs will be fixed on JDK 8, including minor security bugs.
Which Version to Use
The latest version is always up-to-date, including coding features and JVM. This would make the programming more advanced and supported. It would be a good idea for us to always stick with the latest JDK, without the consideration of whether it is LTS or not, though some projects would be struggling doing this.9
About Users
In the discussion, I separated the userbase to technical users and non-technical users. Here, I regarded non-technical users as the computer users that do not know much about computers, but barely some basic functionalities, like word processing, watching videos, playing famous games. Perhaps they do not know how OS works, how programs work, they can still use computers basically. Technical users, who know much more about computers, maybe knowing how to set the computers, how to code, etc. Then, the non-technical users may be struggling about installing Java when they do not know much about it (where to download, how to download). Instead, like some Minecraft players, they know how to download apps from Microsoft Store, Google Play, App Store, etc. Even follow the straightforward instructions on the website. Installing JDK might not like these general apps, there might be some advanced configurations and settings that have to be done on first. To take of these users, using the Launcher is more recommended. Also, Minecraft Launcher does not require users downloading and installing Java and using barely with JAR, Java Archive (not EXE (Windows Executable)). JAR is not like other general executables, it requires JRE to run. It is possible that Java binary is not the "default program", then some users might give up instead. Anyway, it is just a hypothetical situation.3
In this case, it does not matter what Java.com is hosting, just barely how we act, by the actions from users. With the help of the Launcher, we take care of the users on this part. This is also the service-user or service-client relationship in general. We would instead recommend the users to use our client application, the Launcher. This is the use of the Launcher, and also by the conclusion of the discussion.
Conclusion
So, in final words, how should we do then? Under consent, we agree to still release the binary build of Minicraft+ under GitHub release, but with the uncertainty whether to release the binary JAR or the shadow JAR (fat JAR), given that shadow JAR could be really heavy in the future (including native libraries). We might have binary executables for corresponding platforms, but we will still have our Launcher and "CLI" done for this. Eventually we will stick with the latest JDK for the project. Ideally, these will be done in 2.3.
See also
- Discussion by the development core team on "development" channel on 2024-06-23 (UTC). The discussion originally focused on the debates between JDK versions, but later the focus changed to the topic of the Launcher and distributions.
Footnotes
-
Reddit post: "Why is Oracle protecting Java 8 that much?" ↩
-
Wikipedia: Java version history ↩
-
GeeksforGeeks: "Java 8 vs Java 11" ↩
-
Stack Overflow: "Is JDK "upward" or "backward" compatible?" ↩
-
WhichJDK.com: "Which Version of JDK Should I Use?" ↩
-
Pretius blog by Dariusz Wawer: "Java 17 features: A comparison between versions 8 and 17. What has changed over the years?" ↩
-
Code snippet in project:
private static Comparator<Entity> spriteSorter = Comparator.comparingInt(e -> e.y);The bug is fixed in versions later than 8, including JDK 9, but not JDK 8. Bug tracking: JDK-8171499 ↩
-
Incusdata blog by Lewis Coosner: "Which Java JDK Should You Use?" ↩
I have planned it to be one of tasks to be done, close to the beginning of development of 2.3. I understand some people would concern about this.
The point of upgrading project JDK should be beneficial for long-term maintenance, after the period of adaption. There is not always a change that could cause no pains. People must complaint before a problem-solving resolution coming out when there is a dramatic change, but it does not mean we should always stay at the origin. It is not always possible to see the effects and benefits of the change immediately after adoption, but it should be beneficial enough for a longer period. Panics must, and certainly exist, but it depends on how we solve it. There are even no definitely defined governance rules, code of conduct and coding guidelines, so there would be no much issues when proposing major change at the moment, but certainly they should be shaped up afterwards. If there are problems emerging, we should solve it significantly, but not really always reverting the change.
To reduce some works, I suggest sticking with the latest LTS JDK version (currently 21) instead of always switching to the latest JDK version (currently 22). This may also guarantee the frequency working on switching JDK can be reduced at the same time maintaining the JDK and coding quality (quality assurance).
We have already tried this. It was reverted almost immediately. People could simply not open the game, as they didn't have any version newer than Java 8 installed.