MichaIng
DietPi-Software | Java: Allow to install specific/multiple Java versions
Creating a software request
Is your feature request related to a problem? Please describe:
- Bringing attention to this issue now before it becomes more of a problem later. As of 1.17 of Minecraft, Java 16 is required or else it will not function. Issue is older versions tend to break or not work entirely with Java 16 and requires either Java 8/11. I believe currently DietPi installs Java 11. This will impact any Java Minecraft program (not bedrock) in the list (PaperMC, MineOS, Cuberite)
Example: Run a 1.17 server in MineOS and nothing will happen
Describe the solution you'd like:
- Not sure entirely how this should be solved. It could be done by installing both versions of Java, and then providing instructions on the wiki how to specify the version in the various programs. I'd leave Java 11 the default for compatibility reasons, but have Java 16 in the event of Minecraft 1.17.
Note: MineOS's developer Hexparrot has addressed the issue of managing Java versions and will be implementing a webui toggle for it soon, though not sure about the others.
https://github.com/hexparrot/mineos-node/issues/410#issuecomment-862473774
Many thanks for the info.
This is a heavy cut, especially since Minecraft v1.16 supports only Java up to v14 and the next version now requires a min version two major version number higher than the last max version... Not exactly nice for developers of implementations who have to deal with all the user reports about broken compatibility, but they may have their reasons.
In case of MineOS, we can add a hint to our docs that v1.17 does not work unless Java 16 is (for now manually) installed. In case of PaperMC, probably their installer is or will be smart enough to fallback to the latest MC v1.16 when it was not executed with Java 16+. But for Nukkit and Cuberite, as fast as they upgrade their builds, there is currently not really a way to detect it.
We simply install the native Java version shipped by the Debian APT repository, which is Java 8 on Stretch, Java 11 on Buster and it will be Java 17 on Bullseye (currently still Java 11, but Java 17 available, just needs testing).
To enable Minecraft v1.17 on Buster (and Stretch), we could download the zulu JRE builds: http://static.azul.com/zulu/bin/
But they don't ship ARMv6/ARMv7 builds, hence it won't work on RPi 32-bit images.
But there is also AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk17-binaries/releases
They ship binaries for 32-bit ARM as well, requires testing if it works also on the ARMv6 RPi models. There is not much issue to install them aside of other Java versions, as each version/build has it's own distinct directory. It get's interesting when you want to have a specific executable in you PATH (so that you can run it from console without using the full path) or set a JAVA_HOME. But I'd skip that completely (to not mess with possibly installed Debian Java packages) and use the full path to the wanted Java executable and JAVA_HOME via systemd service only.
It requires some testing. In case of MineOS, it's good that they implement an option, as the web UI itself runs with Node.js, so we don't have control over which Java executable is used, and I bet JAVA_HOME is not passed through (which would be good).
Just an update on this. I'd highly prefer to use the non-commercial Adoptium Temurin as replacement for the Debian Java packages, if we generally want to implement multiple Java versions into dietpi-software. However, to keep it slim I'd only go that way when there are dedicated JRE builds available, and currently Adoptium does not release those but only the full JDK. There is an ongoing discussion whether to provide JRE releases as well: https://github.com/adoptium/temurin-build/issues/2683
EDIT: JRE builds are available now.
Since we do now ship Bullseye images (providing JRE 17 packages from Debian) for all SBCs and provide a blog about how to upgrade from Stretch => Buster => Bullseye, for Minecraft resp. PaperMC only, I do not see this being of high priority anymore. Cuberite (and most other dedicated Minecraft server implementations) ships an older Minecraft version and in MineOS one can freely select a version that works, and can even download "embedded" Java binaries(?). So in the latter case we may instead add a note to our docs, which version to select for which Debian version for now.
But there are other software titles with specific Java version requirements, so I see there is some benefit to have more software available on more Debian versions. However, I'll detach this from milestones until there are more related reports/requests.
There is an APT repository now: https://adoptium.net/de/installation/linux/
PR up to implement and use the Adoptium Temurin Java repo: #7663
Problem is, they stopped support for 32-bit ARM after Java 17, and Azul Zulu did the very same. So for ARMv7 Bullseye/Bookworm systems, we need to remain with Debian's OpenJDK packages, and deal with limited Java 17 support for e.g. Minecraft and openHAB.
At least I recognized that the RPi repo provides OpenJDK 17 builds now, which work on RPi 1/Zero/ARMv6. Hence, as we need to serve the old packages and deal with Java 17 support for ARMv7 anyway, it does not cause much additional work to re-enable this limited support for ARMv6 in the same turn.