Supporting bundled java

[oxodao]

I know this would be a lot of work but this could really ease the deployment on end users. This is not a request but a proposal to discuss about this issue and how we could handle it properly if we were to implement it.

The official launcher, being in electron is native and downloads the correct java version by itself.

The idea would be that we build a replacement for the bootstrap in another language (native, e.g. golang / c++ / rust or one with native bundlers like python. This can probably be done with GraalVM in Java directly but I don't know much about it). This bootstrap's job would be like the current one to download the real launcher, but also a working Java version for it as there is no real JRE for newer java AFAIK (I had to make my friends install JDK...)

Once the launcher is self-sufficient, we could assign a JRE version in the modpack's manifest with some kind of API (Maybe with Adoptium's API so that each modpack can specify which version it should use.

The result would be the enduser having nothing to do to be able to play: just download the bootstrap for its OS, run it and everything gets done for him

This relates to this previous issue: https://github.com/SKCraft/Launcher/issues/423

EDIT: Just found out there was something previously started to do this: https://github.com/SKCraft/rusty-bootstrapper EDIT2: After poking around with the launcher, I've written the steps used by the official launcher on the wiki.vg: https://wiki.vg/Game_files

[oxodao]

I see that there is not much interest in this...

Anyway during the past year since making this issue, and especially those last days, I've made my own bootstrap in golang. It's made for my own launcher but since I'm far from having a functional one, I adjusted it so I can use SKCraft in the meantime.

I plan on making it a generic launcher bootstrap so if you want to use it you can. It's still a bit rough but it does the job.

I also made a fork of SKCraft which I do not plan to upstream because the code is more of a PoC than really something worthy of having in this repo but it can give ideas of how I implemented it. Everything is in this commit.

Basically what I've done is added a java runtime to the manifest of each modpacks and when the game is starting, the updater validate that the runtime is installed in the launcher's folder (using the same structure as the bootstrap so if you want to use the same JVM for both the launcher and the game you don't download it twice).

Currently the JVM are downloaded from Mojang but we should mandate the user to host it on their own (by having an incompatible JSON and providing a tool to fetch the releases from Mojang and convert to the correct format), just to be nice with Mojang's bandwidth

This unfortunately, raises an other issue. The launcher owner now has to compile the bootstrap himself. Since I'm using fyne, it comes with a great tool (fyne-cross) that enables cross-compilation easily but the main issue is for Mac OS as it's ALWAYS a pain to build for because of Apple stupid decisions. Theorically, you can use the xcode SDK to crosscompile but it did not work for me. Not sure how to handle this. Crosscompilation from linux to linux (amd64/arm64) + windows (amd64+arm64) is done with no issue at all though.

[hedgehog1029]

sorry about the silence on this! I read the issue, mentally went "yeah sounds good but is a lot of work", and then never replied :sweat_smile:

As you noted the Rust bootstrapper was started to give a jumping off point for something like this. By shifting the bootstrapper to native we can then start to look at having the launcher bundle its own runtime (ideally using jpackage or similar).

I think that's largely a separate issue from auto-managing game runtimes though; that could be implemented even without the bootstrapper changing. I've kind of shied away from it in the past because I know Oracle licensing is an abyss that you don't want to gaze into, but it might be possible to piggyback off the official launcher runtimes without running afoul of the license. It would make the most sense - each game version is specified to run with a specific runtime that the launcher metadata specifies, so by using that same download we would ensure we're not causing issues in-game by using a slightly different Java build.

[oxodao]

Ah yes i didn't think about this but using the official launcher installed java could be nice too so that we can save on space (I have a few friends that play on 128gb macbook that would benefit from this). Though that would require the user to install the versions you want to play on the official launcher before using it in a modpack. I knew oracle tos were a pain but do those also apply on other JVM provider ? Like liberica and adoptium?

A nice thing of having a custom bootstrap though would be that we're no longer prevented from using newer language features in the code (like records)

[hedgehog1029]

Yeah, native bootstrap + repackaging will mean I can upgrade from Java 8. Though I only recently bumped it from Java 6, so there's still quite a lot of old code kicking about.

I don't necessarily mean "just use the official launcher's folders" - the current runtime finder already does that - I just meant "download Java from the same source as the official launcher". We're already downloading libraries from libraries.minecraft.net - it isn't too much of a stretch to download Java runtimes too.

[oxodao]

Oh yeah, did not understand that this way my bad. In this case that's what my PoC is doing. I did add what I found back then to the wiki.vg page I linked in the original post.

I was a bit worried that the URL contains a hash thinking it would probably change regularly but it seems that a year later it's still the same URL