4 ms·

Linux distros still ship JRE and JDK separately (CentOS & Ubuntu, to name a few). There are a few reasons for this: the first one is that libraries will get sha

by dig1 6y ago

Linux distros still ship JRE and JDK separately (CentOS & Ubuntu, to name a few). There are a few reasons for this: the first one is that libraries will get shared [1] between multiple java processes. The second one, probably the most important, is that distro will keep JRE/JDK with security patches up to date. It will usually take a single package to be updated instead of (manually) updating every java app JVM out there. If you run multiple java apps on a single server, per-app JVM can be a problem. [1] Here I'm talking about core JVM libraries sharing (e.g., libjvm.so), done by Linux kernel.

pron 6y ago
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.
- saagarjha 6y ago
  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.
  - pron 6y ago
    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.
    - dig1 6y ago
      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 [1] https://adoptopenjdk.net/releases.html?variant=openjdk15&jvmVariant=hotspot https://adoptopenjdk.net/releases.html?variant=openjdk15&jvm...
      - pron 6y ago
        > 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.

by dig1 6y ago

pron 6y ago

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.

saagarjha 6y ago
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.
- pron 6y ago
  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.
  - dig1 6y ago
    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 [1] https://adoptopenjdk.net/releases.html?variant=openjdk15&jvmVariant=hotspot https://adoptopenjdk.net/releases.html?variant=openjdk15&jvm...
    - pron 6y ago
      > 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.