JLink is only able to link Java modules into the static image, since the images must be self-contained and there is no way to know (from jlink’s perspective) what non-modular dependencies non-modular code has. So in short… until jME gets module-info files added, there is no way to jlink an image containing jME.
However, the good news is that a jlinked image can still load and run code from the classpath at runtime, so you jlink any modules you want into your base image and then distribute and run classpath dependencies as normal with that jlinked VM image.
Hi. Actually, when I said about “jme+jlink evidences”, I meant exactly your messages They are the only relevant googlable information.
So, looks like there are no any successful attempts to use this tandem. I read many articles describing how we can just generate automatic module-info and inject it to legacy jars and it works for many libs (Kotlin, Guava, Apache Commons). Is it possible for jME jars for your opinion?
Now I’m on the first stage, when I’m looking for some magic maven plugin that does everything for me. But looks like I need to dive deeper to have any results, because there are no out-of-the-box tools (actually moditect looks releavant, but I haven’t chance to try it yet).
I do use jME + a jlinked runtime for the MyWorld client - I’m just not able to jlink everything together into a single image. The build is very simple, and with a trivial launcher script it’s quite clean and maintainable.
This is an area I’ve never done anything in, so this is just a guess… but usually it’s reflection that trips up automated tools (Graal native image, for example, can require some auxiliary information beyond the source code for reflection-heavy code), but so far as I know jME only uses reflection in native resource freeing, the networking engine, the serialization library, and maybe one or two other places that I’m not thinking of right now. Reflection is a tricky area with modularized code though, because of access to non-public class members across module boundaries. There are ways around it (opening a module to another), but they require a bit of legwork. Any such issues would come up at runtime for each person using the modularized serialization, but it may not be much of an issue in practice if the reflection is only touching public members. This is an area I haven’t delved into personally. TLDR, I think this stands a reasonable shot at working, but may require some manual intervention.
MyWorld.sh <- MyWorld.bat on Windows
vmArgs.txt <- consolidated, easy place to share all x-plat VM args
MyWorld-Client.jar < - this could also go in ./lib/, as it is just another classpath dependency as far as the JVM is concerned
lib/ <- all classpath dependencies go here
runtime/ <- jlink output goes here
...other directories & files not related to running from jLinked image
Same structure stored in a zip. You can easily build a native installer from this structure too, which I don’t currently do because the current JDK tools for that are still bleeding edge and gave me some trouble.
On Linux, the default is /opt/application-name
On macOS, the default is /Applications/application-name
On Windows, the default is c:\Program Files\application-name; if the --win-per-user-install option is used, the default is C:\Users\user-name\AppData\Local\application-name
allowing you to only change the dir name inside those destinations.
Doesn’t this render jpackage useless for gamming because by restricting to those folders you cannot write to disk?
I can’t seem to find the trick that allows other programs to run updates to their apps from those folders.