Why does it download a JVM separately instead of packaging the app with jpackage (which would result in a much smaller footprint)?
EDIT: I mean jlink - jpackage would be an alternative to creating installers, but jlink just packages the app with parts of the JVM it requires, which seems could make this tool better by avoiding the need so maintain JREs (which are deprecated) on the user's machine.
By managing the JVMs separately, you get major savings on updates, or if you have multiple apps deployed this way since they can share a JVM. When you update your app, it only needs to download your app - not the whole JVM. You can even change the JVM requirements in your version updates, and it will adjust to the new requirements when it updates, possibly even downloading a new JVM if it doesn't have one that meets the requirements yet.
The JVM updates very often now. This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM (as others pointed out, downloading two apps from the samples already shows the problem).
With jlink , you don't need to download a whole JVM, it's usually a much smaller distribution. I have a LogFX application I distribute after passing it trhough jlink and it's around 30MB.
> This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM
Not really. Currently it supports Java 8, 11, and 17. For each of those there is a JRE/JDK option, and a JavaFX option. Plus some of these are subsets. E.g. An app that doesn't need JavaFX can still use the JRE with JavaFX. And an app that doesn't need the full JDK can still use the JDK.
> as others pointed out, downloading two apps from the samples already shows the problem).
This was just an issue with the installer not needing JavaFX so downloading a non-javafx JRE first - but then the app needing JavaFX, so downloading one with JavaFX. This is a special case that will be resolved in an upcoming release by making the installer use a JRE that is compatible with the app to avoid the double download.
Anyways these are "fixed costs". Only incurred on first install. And, even then, maybe not if a compatible JVM is already present. All of your updates go through without the baggage of a JVM.
If you need more specific control over which JVM you're using than this (e.g. a specific build version or distribution), then jlink is a good tool for that. Life is about tradeoffs.
EDIT: I mean jlink - jpackage would be an alternative to creating installers, but jlink just packages the app with parts of the JVM it requires, which seems could make this tool better by avoiding the need so maintain JREs (which are deprecated) on the user's machine.