> The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one. This is complicated. The Java SE spec is very stable. But, unf

> The point is that the jar<->jvm interface is a lot more stable than the jvm<->host system one. This is complicated. The Java SE spec is very stable. But, unfortunately, many libraries and applications don't just program to the spec, and, rather, hack into the runtime (which is much more than just the JVM) and in that case their compatibility becomes much less stable than the VM<->OS one. This is changing soon with encapsulation (finally!) being switched on in 16, although applications will still have the option to selectively disable it, essentially saying, yes, we're giving up on portability but we know what we're doing. > XML or CORBA I can easily imagine most of its attackable service being JVM code that the application really does use. They're not in the JDK either, anymore. I don't think that the statement that most vulnerabilities will likely be in the runtime is true. > Wasn't that the point of Java Web Start links? I usually favour leaving things up to libraries, but at the same time things need to be secure by default. Yes, but it wasn't as good as we wanted. The problem is that Web Start still centralises the runtime and forces the user to interact with a third party. It's better for the application to choose how to manage its updates. This could, indeed, be done in a library, and I don't see why it would be any less secure than the JRE. > So encouraging every application to ship a static copy of the same chunk of well-known low-level code has a significant downsides - any vulnerability will become the equivalent of that zlib double free where essentially every MacOS program had to ship a new version. But it's not the same chunk. jlink customises the runtime to only contain the modules the application actually needs. This means that the JDK modules are like any other dependency, and there's no good reason to have a different update mechanism for them, which would also be controlled by a third party, especially since you'd need the application and dependency update anyway.