[Feature Requesŧ] Have PolyMC manage its own Java version

[TheFrenchGhosty]

During my move away from MultiMC I used GDLauncher https://github.com/gorilla-devs/GDLauncher and one thing I found better than MultiMC was that it manage its Java version itself, by downloading (and updating) on its own OpenJDK JRE 8 and 17.

This is in my opinion something PolyMC should definitely do, and would definitely makes deployment easier.

[ghost]

probably would be best to have an option to use the system version if desired.

Questions:

• where would we store the JDK/JRE?
• should we use Adoptium?
• Keep a version for each instance or have both stored in the PolyMC files, separate from instances?
• default to system or local version?

[TheFrenchGhosty]

GDLauncher can use the system one, it has to be linked to a JRE 8 and a JRE 17.

• Like GDLauncher, in it's folder
• Any OpenJDK build is fine
• Stored directly in PolyMC

Honestly I recommend you to try GDLauncher, I prefer PolyMC, but the way it does Java management is so much better.

[ghost]

alright, sometime over the weekend I'll look through GD's code for all that. If there are any other features from GDLauncher that you would like added don't hesitate to ask

[d-513]

Honestly, IMO a perfect compromise is having a "java downloader" in the Auto-Detect screen.

• Downloads to PolyMC install folder
• Automatically detects javas from that folder This way, by default, you can use the proper way of managing javas system-wide, but you can also easily do it in the launcher

[d-513]

also I dont think its as simple as 17 and 8. Heres the compatibility:

Minecraft version	Java version
=< 1.11	Java 8
1.12 - 1.13	Java 8 or 11
1.14 - 1.16	Java 8, Java 11, Java 14, Java 15
1.17-1.18	Java 17

[ghost]

In that case, I think it best to have 8 as the default for <=1.16, allow alternate versions if desired (through the auto detect screen), and automatically download 16/17 for 1.17 and 1.18 respectively.

Okay a million ideas just popped into my head, I'll sort them out:

• This should be opt-in.
• We can put this in the setup wizard. There should be a checkbox to turn this feature on. It would have a note that is something like:
  • PolyMC will automatically download Java for you if this option is selected. Otherwise, it will attempt to use the system Java, as set in Settings.
• Then, when selected, a new box will appear, containing:
  • Note: These Java versions will be downloaded right now. This may take some time. You can always download or delete these later.
  • Table like the one you sent
  • Then the selections.
• In auto-detect screen:
  • New button: Download Java version
  • Pops up a window to choose which version (same as the box from the setup wizard)
  • Auto-Detect will need to search the local JDK directory. This can be achieved by adding to the Java utils the new location (like in your Flatpak PR)
• On downloading:
  • Use adoptium, it's the best version
  • IF the user already has that version installed system-wide, give a warning and potentially refuse to download unless the user is 100% sure they want this.
  • Need to figure out a way to directly download the JDK. It can be stored in <PolyMC Data Directory>/jdks.
  • We could allow for downloading ANY Java version for experimentation.
  • We could show a guide for the user to install it system-wide if desired. This could show for different OSes and distroes.
  • Obviously need a progress bar so the user knows that the application didn't freeze on them

Cool, this could work.

[ghost]

okay it appears Adoptium lacks version 14 and 15, so we will need to get that from somewhere else

We could get them from jdk.java.net (i.e https://jdk.java.net/java-se-ri/15). And we could provide IcedTea for 8 as well. This requires some discussion

Also I forgot to mention but we need to verify via SHA256

[d-513]

we should have a drop down that lets user choose if they want JRE or JDK, JRE is the Java runtime and JDK is runtime and devtools. JRE is way smaller

[oldherl]

Please don't download JRE on Linux. It's against the usual practice (to use the system one). If anyone is going to implement a Java-downloader, please restrict it to Windows or macOS only. Thanks.

[d-513]

@oldherl it would be completely optional to the user. This is useful in situations where you are restricted to portable builds. While you should use system package manager, it’s still a nice feature

[yemouu]

Could also be useful in the future if Minecraft ever depends on a non LTS version of java like it did in 1.16. Some distros like Gentoo tend to only package LTS versions of java.

[d-513]

Yeah honestly I’d much rather use this than add system repositories just to get latest version

[lonjil]

Another thing that could be nice is having some easy way of using Flatpak JREs. I have no idea how that kind of add-in flatpak stuff works though.

[d-513]

Another thing that could be nice is having some easy way of using Flatpak JREs. I have no idea how that kind of add-in flatpak stuff works though.

If it installs the javas to the data directory of the flatpak, sure it could work. Currently the flatpak is bundling Java (version 8, 11. 16, 17), but if the downloader is implemented we could just bundle 17 and let user install other versions

[DioEgizio]

okay it appears Adoptium lacks version 14 and 15, so we will need to get that from somewhere else

We could get them from jdk.java.net (i.e https://jdk.java.net/java-se-ri/15). And we could provide IcedTea for 8 as well. This requires some discussion

Also I forgot to mention but we need to verify via SHA256

you could use azul zulu or any other openjdk builds too tho

[d-513]

Azul Java can be used, they have arm too and jre. They have most versions

[HalJordan]

I can't say this without the obligatory phrase .... but do any other disto's handle java the way Arch does? It has side-by-side installs, you can set the default system version, but then if you have some obscure app that you're still waiting to update to a modern release, you can appease it temporarily.

I use Arch btw(whew, now I feel better /s)

[d-513]

I can't say this without the obligatory phrase .... but do any other disto's handle java the way Arch does? It has side-by-side installs, you can set the default system version, but then if you have some obscure app that you're still waiting to update to a modern release, you can appease it temporarily.

I use Arch btw(whew, now I feel better /s)

On Debian based you can install multiple too and set default via update-alternatives, but Debian has outdated packages

on Fedora it’s the same I think but Fedora has up to date

[DioEgizio]

On Debian you can install updated java through the Zulu repo. About fedora, yeah, it has updated java in official repos

[UnlimitedCookies]

I would say this is most likely really only needed on Windows systems. The auto-detect mechanism works really well for me on GNU/Linux. On Windows PolyMC could potentially help the user install the correct version from adoptium.net (previously known as AdoptOpenJDK).

Where PolyMC could shine on all systems is that it would suggest (but not install) the best java version for the corresponding Minecraft version. MC 1.8 e.g. requires java 8 while 1.18 for example requires a modern version of java.

[ghost]

I would say this is most likely really only needed on Windows systems. The auto-detect mechanism works really well for me on GNU/Linux. On Windows PolyMC could potentially help the user install the correct version from adoptium.net (previously known as AdoptOpenJDK).

Where PolyMC could shine on all systems is that it would suggest (but not install) the best java version for the corresponding Minecraft version. MC 1.8 e.g. requires java 8 while 1.18 for example requires a modern version of java.

This is what I was thinking actually.

For example, upon creation of a new instance:

• Check if this version has a supported Java version installed.
• If so, continue on
• Otherwise:
  • On Linux, tell the user to install through the package manager, and give instructions per-distro (on website or wiki), or install systemwide in /opt/jdk{s,}.
  • On Windows/MacOS, give the user a direct link to installers for each supported Java version. Probably use Azul because it has JRE

[HalJordan]

Only issue with that is fragmentation. There's so many you'd have to contend with, but if it could at the very least say:

The version of MC used in this pack plays best on/requires Java 1.X, do you wish to try continuing with the current default(1.Y) or abort until you can get that setup?

That alone would be a massive QoL improvement.

[TheFrenchGhosty]

also I dont think its as simple as 17 and 8. Heres the compatibility: Minecraft version Java version =< 1.11 Java 8 1.12 - 1.13 Java 8 or 11 1.14 - 1.16 Java 8, Java 11, Java 14, Java 15 1.17-1.18 Java 17

Having Java 8 and Java 17 is enough, you don't need to ship 11-14-15

Adoptium/AdoptOpenJDK is 100% the way to go.

[rafalohaki]

Would be great to somehow be possible to import custom json with custom jar mc version

[glowiak]

Automatic downloading of Linux java binaries would just waste disk on *BSD

[d-513]

Automatic downloading of Linux java binaries would just waste disk on *BSD

It would be optional and when enabled would download the correct BSD java

[stephenseiber]

should note some packs on 1.16 work with java 17 engimatica 6 for example if it uses forge 36.2.29 it runs on java 17

[glowiak]

For me, who already has all the JDKs in /usr/local/openjdk*, it would be a diskwaste

[DioEgizio]

Still, it will be optional

[d-513]

For me, who already has all the JDKs in /usr/local/openjdk*, it would be a diskwaste

do you read replies? I''ve said before that it's optional and you could disable it.

[stephenseiber]

@dada513 would it be hard for it to check for Java installed

[DioEgizio]

wdym that's how it is now...

[Jarfeh]

Might it be possible to suggest the OpenJ9 builds of Java provided by IBM?

[d-513]

Might it be possible to suggest the OpenJ9 builds of Java provided by IBM?

hotspot JVM is better in majority of cases

[DioEgizio]

Yeah

[izwk]

Would be great. One thing to keep in mind though plz don't make it the default. This is one thing I like about PolyMC (and by extension MultiMC) is that it doesn't install a jre by default because I have limited space and since I like to make mods and other java stuff I can keep only one instance of java installed and use it in PolyMC.

[d-513]

Would be great. One thing to keep in mind though plz don't make it the default. This is one thing I like about PolyMC (and by extension MultiMC) is that it doesn't install a jre by default because I have limited space and since I like to make mods and other java stuff I can keep only one instance of java installed and use it in PolyMC.

everyone here agrees that its not gonna be the default

[izwk]

everyone here agrees that its not gonna be the default

Great then. 👍

[DioEgizio]

now that i think more about it, maybe we should use mojang jres here.

Advantages:

• fixes weird device-specific stuff like and this
• more future-proofing if a new mc version needs a different jre
• more tested

Disadvantages:

• no builds for special stuff (arm/musl/bsd)

[DioEgizio]

what if we use mojang jres on supported systems and normal openjdk (azul/adoptium) on the other systems?

[DioEgizio]

ok this is my full idea:

• PolyMC has an option for downloading jres automatically. You'll be able to choose if having it or not, but enabled by default.
• PolyMC downloads mojang jres (and other openjdk distros on unsupported systems) into a polyjres folder or something like that
• PolyMC will automatically use the jre that matches best the compatible major on the instance

this is just an idea, but i wanted to share it here

[HalJordan]

The only kicker is the pack authors will have to start including the desired version with the packs, unless you're just going to go with the forge/fabric version(where applicable) and MC version, whichever's higher.

[DioEgizio]

what do you mean

[derspyy]

My take on this idea (which prompted me to lurk into this page) was to just have an option where you can input a path to both an 8 and 17 jres (along with jvm args) so that it uses the built-in java check to choose between them. In my opinion, it wouldn't be very great for it to download jres, but organize them. This way, the user has control over their installs. Also, you wouldn't have to manually change the java version separately on each instance. 😄

Goofy ahh example:

[DioEgizio]

That idea has a flaw: if Minecraft will require another jre, polymc will need to be updated to add yet another jre

[DioEgizio]

But otherwise, pretty cool but this issue is about java downloading, that's more like #284

[Abalieno]

I've run some tests for performance, and a good option is to use https://github.com/graalvm/graalvm-ce-builds/releases

They can be downloaded directly from there, and only a .zip to unpack. So it would be easy to both fetch and use internally... (you have to scroll down to an early version, for Java 8)

[Xetaxheb]

didn't read all this so not sure if it was covered: 1.16x is a special case (maybe others but this is the big one)
some mods require java 8 explicitly, some require 11+, some require 14+

[DioEgizio]

If a mod in 1.16 requires a version higher than 8 than its broken and should be fixed by the mod author

[Xetaxheb]

If a mod in 1.16 requires a version higher than 8 than its broken and should be fixed by the mod author

why would that be broken? there are useful features.