So Java 9 added the concept of “runtime images” - unlike the old JRE, these contain only the VM itself and whatever JRE “modules” you specify to include. The result is a custom runtime that (a) runs only on the platform you built it on, and (b) includes only the standard library packages that were in the modules you selected. After it’s built, that’s it - you can’t really customize it per se (although at runtime you can still change the classpath/module path via command line arguments).
Sort of - to build an image for Linux, you need to have a Linux machine to run the
jlink on. Same for Windows, Mac, etc. It’s not cross-platform in the sense of building the VM image once and running it anywhere.
What we’d have to do is
jlink the runtime on each OS that we want to target (as part of the SDK build process) and include all of those pre-built runtimes as part of the distributed SDK. It’s no materially different than building the jME native bindings for each target platform.
That’s why they’re talking about needing the “extra” Windows machine - the developer was working on Linux but needed a
jlinked VM for Windows. Once you’ve built the VM once you don’t need to do it again (unless you want to include more modules or you’re updating to a new VM, etc.).