The jlink’ed JVM seems to lead to some specific kinds of problems.
Bringing a tailor-cut JVM sounds convenient at first, but:
We have a case where a user is not able to switch the look and feel by
supplying the -D parameter.
Another case where the application doesn’t run at all with the bundled
JVM but runs with his system’s JVM.
Do we have evidence that either of these are caused by the JVM we produce
with jlink? If so, what?
Potentially, modules could be using JVM modules in their custom code
which are not bundled, i.e. the bundled JVM does not support all 100% of
the Java language
This is worrisome. But, will anyone realistically use what’s left out?
(Yes, I’ve already added in the handler for HTTPS URLs—but that’s
something I’d assumed was already there, not something esoteric that
no one will use.)
After we remove the includes, jmods, src.zip, and a few other things,
the what we ship will top 200MB. Is that too large?
How about this idea - we bring a full, regular JVM and not a jlink’ed
“castrated” version of it? This should remove at least some of the
issues, and would also make the build process simpler.
It would make the build process a bit different, but not only marginally
simpler. About six lines would be removed from the Makefile, then replaced
by about the same number of lines copying the JDK to where it needs to be.
And if we do this, we should be bundling a 100% free / opensource JVM,
none of this Oracle stuff. Adopt or Zulu are best choices.
The one we’re distributing is OpenJDK. I’m no fan of Oracle, but this is
under the GPL. So aren’t we already bundling an open-source JVM?
Yes the increased download size might be a high price.
The “regular” OpenJDK is fine, Zulu goes even further and has a build process which scans every single source file for the proper license headers, and says their OpenJDK variant is “certified” to be opensource.
The JVM modules we ship, yes they are probably more than enough for 99.9% of all custom module classes. I am not entirely sure what we ship but I guess the ones we don’t are those having to do with management and jvm internals. And even if some modules use parts that aren’t in our distribution, they will probably speak up and let us know what we need to add.
Overall, I’m not 100% sure myself. It used to be common practice to ship full JVMs, there’s still too little experience with these stripped down JVMs. Even if the stripped version works, I just think we would have one thing less to worry about if we shipped the full JVM, the jlink-castration still feels a little bit experimental.
And what is going on with that one commit saying “jlink sometimes adds a newline to its output”, how is that even possible, is it not a deterministic process
No, seriously. These bundled stripped down JDKs, I don’t know.
Maybe the jlink version / bitness used to bundle it has to be the exact version of the bundled JDK, maybe it needs to be a 32-bit windows jlink.exe to properly work on a 32bit windows.
Just add the full Adoptopen VM.
Or just put a link to the Adoptopen site and tell the users to install it themselves… It’s not 2005 anymore when the Java installer was bad and left the system in an undefined state. The installers are good nowadays.
Well, I do want to speak up and say ONE thing I know from being in the games business and dealing with “entertainment products” and the consumers thereof, and that is: every single bit of friction you put between your game and your player (user) has a substantial impact on your total “reach” i.e. potential install base.
Being told to go get a Java JDK (“whatever that is”) and have to download it from some scary page that doesn’t look like a game site, and probably answer a bunch of questions and accept a bunch of terms, and THEN you can try this cool Vassal thing… THAT’S a LOT of friction!
If occasionally a custom-module-code person has to post and ask us to “compile in” some piece of the JDK that’s missing from our bundle, that seems a fairly reasonable price to pay for the lack of friction (and therefore far higher likelihood of increased “Vassal adoption”).
One possible “middle road” would be to offer users an unbundled option i.e. if they already had a JDK?
You are right. Sometimes I forget that I’m a power user
Forget my very last suggestion then.
I looked closer at how Minecraft does it, and they do the following:
they have a launcher that needs to be installed, it comes with a bundled JVM, a regular, pre-jlink pre-jigsaw 1.8
except on Linux, where the launcher installer is simply a .deb file and uses the regular debian-style dependency management to install a JVM i.e. if the user already has one, no new one is installed, otherwise it pulls the standard JVM from the package management system (but this is a whole other story, we cannot expect big old operating systems that cost money like windows and mac to be as convenient for the users as a modern linux is, which is free)
inside the launcher, the (power-)user can optionally select a JVM from his computer, or leave the setting on default, which is the JVM that is bundled with the launcher
Applied to Vassal, this could look like this:
we bundle a full JVM, not a stripped one, not jlinked, no jigsaw puzzles, just a regular JVM
we have no launcher like Minecraft but the power user will find a way to use a JVM of his choice, or we give them an instruction on how to do this via command line, in that one thread I already got a non-power user to run Vassal using his local JVM 14.x.x
I think the full JVM is the safest approach, and we can use the safety as we don’t seem to have enough testing resources to test all the possible Vassal distributions. In particular, we cannot test whether that stripped VM which comes out of jlink for windows32/64 and macos is good enough to run Vassal.