quilt-loader icon indicating copy to clipboard operation
quilt-loader copied to clipboard

Rationalize whether we should update to Java 17

Open TheGlitch76 opened this issue 3 years ago • 16 comments

In the latest snapshot, Mojang updated the Java version of Minecraft to 16.

We should strongly consider doing this for Loader too (remember, not only Loader is affected by this but also its dependencies like ASMR), but there is one big caveat: Older versions will have a CME at random times in-game.

There are several options:

  1. Do nothing and stay on java 8
  2. Update to java 16, drop support for <1.17 versions entirely and leave older versions to a Legacy Fabric-style project, since Quilt is only maintaining 1.17+ QSL anyway.
  3. Update to java 16 and leave the game breaking bug present in older version
  4. Update to java 16 and package the Voyager fix in Loader.

What should we do?

TheGlitch76 avatar May 12 '21 14:05 TheGlitch76

Doesn't fabric do the latter part of the 4th option natively as of now?

Edit: that was FAPI, not the loader

Geolykt avatar May 12 '21 14:05 Geolykt

I would hope mojang addresses the CME issue before the final release of 1.17.

I do think we need a wider discussion about what can use Java 16 here, for now we should avoid bumping too much to java 16.

For now I think it would be a good idea to make sure that everything using CI gets tested on Java 16

i509VCB avatar May 12 '21 14:05 i509VCB

  1. This is the best option I think. Java is backwards compatible, and Loader should be compatible with 8. Hopefully Loader itself will be lightweight so this shouldn't be too much of a pain.
  2. Ideally Legacy Quilt should not have to fork Loader just to get the game running, that goes against our loader plugins idea.
  3. Isn't this equivalent to 2? Anyway, to be honest, this is the best option if we do decide to update Loader to Java 16. Fixing bugs should be up to mods, and Legacy Quilt can recommend to install a mod which fixes this bug in their installer.
  4. No, it should NOT be up to Loader to fix bugs in the game, that goes far too far down the route of scope creep that Forge has for my liking.

Earthcomputer avatar May 12 '21 15:05 Earthcomputer

the difference would be that # 2 is a hard break but # 3 still has the code in Loader to run versions <1.17, I will update the issue description.

TheGlitch76 avatar May 12 '21 15:05 TheGlitch76

Depending what we do with the Minecraft game provider, we could mandate Java 16 for the game provider but keep loader's API at Java 8. Whether we do a separate repo or slap it in QSL is another question for the Minecraft game provider. We don't have a concrete path here yet so we are going to wait on it.

For now I expect we will continue on Java 8 in loader

i509VCB avatar May 12 '21 15:05 i509VCB

Would it be possible to mandate java 16 for ASMR as well? I'm unsure if that's the right path but would like to have the bases covered.

TheGlitch76 avatar May 12 '21 15:05 TheGlitch76

That depends on how we're planning on attaching ASMR to Loader. I want to replace Mixin with ASMR in 1.18 at the earliest, so 1.18 mods will be required to use ASMR instead of mixin (in the backend of course). However, old mods still need to load.

Earthcomputer avatar May 12 '21 15:05 Earthcomputer

Seeing as how loader doesn't need anything from Java 16 at the moment, I see no reason to use it as long as it doesn't prevent modders from using J16.

RedstoneParadox avatar Jun 08 '21 00:06 RedstoneParadox

While I don't think it's necessarily a good idea, I think using something like Jabel should at least be considered.

leo60228 avatar Jun 08 '21 00:06 leo60228

Unless using J8 with loader makes J16 unusable, implementing Jable to work with quilt-loom would probably not be worth the hassle.

RedstoneParadox avatar Jun 08 '21 01:06 RedstoneParadox

To my knowledge, it should be able to work just fine. C2ME, whilst to some may be concerning, does require Java 11+ to my knowledge, so modders should be able to use J16 features on loader unless Im wrong and dumb and its some random incompat on C2ME's part or Im completely misremembering.

Siuolplex avatar Jun 08 '21 01:06 Siuolplex

If we come across an issue in the future where we need an api from a newer java version to support said version, we can consider multirelease jars

i509VCB avatar Jun 08 '21 01:06 i509VCB

I fully support using the latest LTS release of Java. Not Java 16, nor whichever version Mojang decides on in the future.

  • Update to Java 17 to take full advantage of the features it has to offer. My favorites are records and
  • Forget Java 16, support has already ended and Java 17 is already fully released.
  • Forget Java 8 because official support is on its way out and it's possible to provide full backward compatibility in the latest version anyway.

By the end of Quilt support for Fabric, I don't think these arguments make a big difference anyway. Version 16 or 17 will be the minimum Java required to develop for Quilt's minimum version of Minecraft. I think we should support Java 21 by the end of 2023 to take advantage of its features as well, but definitely by the end of Oracle/Eclipse support for Java 17.

Q: "But Mojang delivers JRE 16 in the official launcher!" A: So? We can check for existing installations and provide Java with Quilt Loader's installer just as easily. Mojang often makes questionable decisions and supporting Java 16 is one of them. I've been meaning to bring this up with MultiMC, they should provide Java as well. It can be very frustrating for new users if it has to be installed manually.

halotroop2288 avatar Feb 25 '22 05:02 halotroop2288

you know you can update to java 16 and target java 8 right? i don't think there's a problem in doing so well, there is one, you can't use J8+ APIs, only language features...

ENDERZOMBI102 avatar Feb 25 '22 07:02 ENDERZOMBI102