> Why isn't shipping the runtime with the code a more common practise?
It really shouldn't be. It bloats everything. Containers are bigger. Software is bigger. There's no reason to do this, since very few apps use the entire surface area of a runtime (Python, Node, Java, etc).
Instead, a native GraalVM binary can embed all these things, including only the portions which the application needs to run. Thus it behaves like a dynamic piece of software during development, but a static, high-performance, low-surface-area-of-vulnerability native binary in production.
> That's what I actually do for our product. The JRE is shipped with it as well as startup scripts
Please, as a user, I implore you to look into native targets. It's not as hard as it seems anymore. Some thins really do need Jlink.
> I guess the native compile thing is more for "Java on the Cloud"
Not so. GraalVM is great for embedded development. It's great for desktop development or even shared native library development.
> Java on the cloud seems like a waste of resources to me.
There is no difference now between C++ "in the cloud" and Java "in the cloud" except Java remains memory safe by default.
> Please, as a user, I implore you to look into native targets. It's not as hard as it seems anymore. Some thins really do need Jlink.
You are not my target. It's enterprise software - I'm given a Windows Server VM and the rights to install our software, that's it. Most IT admins don't even want to bother to install or let alone support JRE updates. We got tons of customers and this experience is uniform.
> It's great for desktop development
For desktop I'd totally use Jlink. Really the only possible place GraalVM's NI seems like a plausible fit to me is CLI tools and Java Microservices, where fast start and low memory consumption actually make sense. edit: But honestly at this point for Microservices I'd probably go with Go.
It really shouldn't be. It bloats everything. Containers are bigger. Software is bigger. There's no reason to do this, since very few apps use the entire surface area of a runtime (Python, Node, Java, etc).
Instead, a native GraalVM binary can embed all these things, including only the portions which the application needs to run. Thus it behaves like a dynamic piece of software during development, but a static, high-performance, low-surface-area-of-vulnerability native binary in production.
> That's what I actually do for our product. The JRE is shipped with it as well as startup scripts
Please, as a user, I implore you to look into native targets. It's not as hard as it seems anymore. Some thins really do need Jlink.
> I guess the native compile thing is more for "Java on the Cloud"
Not so. GraalVM is great for embedded development. It's great for desktop development or even shared native library development.
> Java on the cloud seems like a waste of resources to me.
There is no difference now between C++ "in the cloud" and Java "in the cloud" except Java remains memory safe by default.