No one ships a JRE (for versions after 8) because it no longer exists. Some distributors ship runtimes that they call a JRE, and the main (and pretty much only) reason for that is that some people are used to the old way and this gives them the illusion it still exists. It's a harmful practice, and such runtimes should not be used. Developers can use the runtime in the JDK, and end-users should use runtimes embedded in applications. The security story for embedded runtimes is both easier and safer, because each and every application needs to be updated anyway for vulnerabilities in the application itself or its dependencies, and embedded runtimes have a lower attack surface-area, as they include only modules the application actually needs.
Your argument is very similar to the one that people pushing static linking make. As such, “just update the application” has the exact same response: nobody is going to do this.
I a not making an argument, I am explaining the situation, which is true regardless of what people think about it. I'm also not saying "just update the application." It's up to you how to maintain your software, but if you don't, the situation was just as bad with the JRE.
Maybe I'm missing something, or for the OpenJDK team, JRE means something else, but how AdoptOpenJDK still provides JRE builds [1] for all versions from version 8? You are saying that their JRE build is JDK but 4x smaller?
> The security story for embedded runtimes is both easier and safer, because each and every application needs to be updated anyway for vulnerabilities in the application itself or its dependencies, and embedded runtimes have a lower attack surface-area, as they include only modules the application actually needs.
So, you are saying that if someone discovers a security bug in Java/JVM 11.x (assume the latest official version), it is a better practice to update every application on servers instead of just pulling down newer JVM build and let package manager do the magic? Sounds promising /s :S
> You are saying that their JRE build is JDK but 4x smaller?
I am saying they're distributing a runtime image and calling it a JRE, even though it isn't (i.e. it isn't centrally managed). Also, the IBM team that builds the Adopt distribution are not involved with OpenJDK and are a bit confused about the project, but, to be fair, even competent vendors, like Azul, provide runtime packages that they've chosen to call (confusingly, IMO), JREs.
> So, you are saying that if someone discovers a security bug in Java/JVM 11.x (assume the latest official version), it is a better practice to update every application on servers instead of just pulling down newer JVM build and let package manager do the magic?
No. First, you could let the package manager do the update either way. An application vendor still has the option of sharing a runtime among apps; the point is that it is up to them. Second, you need to update all of your applications regularly regardless. They have security vulnerabilities, too. Instead of having different update mechanisms for different application components, each application will have one update mechanism of its own choosing.
