3 ms·

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

by 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

> 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.