> Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation.
This is incorrect. Jpackage creates an installer which will unpack the VM image and any other resources.
I've tried it with a small CLI tool and it actually doesn't work that well (at least on Windows).
Jpackage bundles a small Java VM (with only the features you use) together with your compiled bytecode into a single executable. When it runs it starts up the VM and executes bytecode on that VM exactly the same as it would be if you were to run a jar on a preexisting JDK/JRE installation.
Graal compiles your full app ahead of time into a native code binary. There is no bytecode/translation happening at runtime. That is why GraalVM advertises faster startup and lower memory footprint.
So there are essentially 3 ways to run JVM (Java/Scala/Kotlin/...) code:
* compile into bytecode jar -> requires existing VM runtime
* compile into bytecode jar + bundle VM runtime -> no dependencies required, runs as the previous option
* compile into native binary -> no dependencies required, runs native, starts and runs faster