4 ms·

Here's my recommendation (I work on OpenJDK at Oracle): If you're using the current JDK version (recommended for regularly maintained applications), it doesn't

by pron 5y ago

Here's my recommendation (I work on OpenJDK at Oracle): If you're using the current JDK version (recommended for regularly maintained applications), it doesn't matter which distribution you choose, as they're all pretty much identical. If you're using an old version (LTS, intended for legacy applications, which might benefit from it), pick a vendor you trust for OpenJDK support, as the builds are not the same, and neither is the support. After Oracle, which contributes about 90% of the work on OpenJDK, the companies distributing builds that contribute to the project and have experience with it are (in rough order of experience and/or contribution): Red Hat, SAP, Azul, Bellsoft, and, more recently, Amazon, and Microsoft. There are, however, a couple of standouts: Alibaba's Dragonwell, which, last I looked, did not meet the Java specification, and Eclipse Adoptium, built by IBM, which is the only distribution built by a team that isn't involved with the OpenJDK project, isn't very familiar with it, and isn't a member of the OpenJDK Vulnerability team, and so get security patches only after the other vendors have delivered their builds.

ed25519FUUU 5y ago
Interesting about a Adoptium, since that’s the recommended JVM in the article.
- mayli 5y ago
  I was using adopt jdk since that's much easier to download the jdk (especially jre) for Windows and Linux. The new Adoptium didn't git a jre build, which is sad :(
  - flatiron 5y ago
    Honestly if you are using Linux you should be using the distros Java.
    - krzyk 5y ago
      Why? Distros javas are usually way too old to use.
      - flatiron 5y ago
        I use debian on servers and their Jdk has given me 0 issues I develop on arch and they have a great jdk system as well.
      - Seirdy 5y ago
        Almost all distros ship at least openjdk-11, and many including Debian have openjdk-17 now.
        krzyk 5y ago
        Cool, but did they had 16? Or will they have 18? I use the newest Java version available.
        dtech 5y ago
        In most environments it's better to use a LTS version
        krzyk 5y ago
        In most environments it is better to use latest JDK release not some old one. LTS is associated not with version number but with vendor that provides JDK. So if you don't pay any vendor then you don't have LTS, you just have a number and hope it is in some way better thant any other number - which is not. OpenJDK has no notion of LTS, they release new versions every 6 months, vendors decide which one of those will be supported with fixes, e.g. Azul decided that their JDK 13 and JDK 15 will be supported with fixes for longer their JDK 12 and 14.
  - zylepe 5y ago
    The jre is deprecated in favor of jlink, they have an explanation here: https://blog.adoptium.net/2021/10/jlink-to-produce-own-runtime/ https://blog.adoptium.net/2021/10/jlink-to-produce-own-runti...
  - Erlangen 5y ago
    SAP provides a friendly interface for both JDK and JRE for Windows and Linux. https://sap.github.io/SapMachine/ https://sap.github.io/SapMachine/
mayli 5y ago
> Recommendation: Do not use Oracle Java SE Development Kit (JDK), unless you know what you are doing.
easton 5y ago
> Eclipse Adoptium, built by IBM, which is the only distribution built by a team that isn't involved with the OpenJDK project Wasn't AdoptOpenJDK the "legit" recommendation a couple years ago? I only heard about all of these other versions sometime later. (Looking again, it looks like the Oracle OpenJDK is shipped in Ubuntu's repos, so maybe I was mistaken).
- dtech 5y ago
  It was, it recently transferred to Eclipse
- didibus 5y ago
  > Wasn't AdoptOpenJDK the "legit" recommendation a couple years ago? It was the recommended choice by random internet users who posted blogs, just as is this website, a random website by some random person. The best way for you to understand which JDK to use is to understand superficially what is involved with the source code and the build process between vendors, and their licenses. Source code starts out the exact same, that's why they are all OpenJDK, because they take the source code from the OpenJDK public repository's main branch. From that point on, they can choose to apply source code patches from OpenJDK that have not yet been merged into the main branch, or they could apply their own source code patches. Those patches often will be security fixes, or backported features. Here you have to understand that there is only one main branch of Java. So if you want security fixes or new features but are still on say Java 8, someone has to pull the old commit that was tagged Java 8 and selectively cherry pick a bunch of commits afterwards to apply over it that retrofits all security fixes and possibly a few select new features (like say some performance improvements patches). And if you've ever had to do a cherry pick merge on old code, you know it can be tricky and sometimes there are conflicts and maybe you even need to manually resolve them. And even if they are not grabbing the source from an older tagged version commit, but are grabbing it from the latest tagged commit (so as of this writing Java 17), well it might already be that there are some newer commits that fixed some security bug, or other bug, or improved performance or startup, etc. So in their build of Java 17 they could even decide to apply some of those patches that happened after to the Java 17 latest release. And they might even choose to apply some patches that haven't even made it to the main branch yet, so maybe still have an open PR, or they are the ones patching something of their own. After having grabbed the main source of OpenJDK, and potentially applied some patches to it, they proceed to build it for one or more platforms. In the process of building, they will choose which platform to build for, such as Windows, Linux, MacOS, x64, ARM64, x86, etc. And they will choose what to include in the build, for example should you bundle Java Mission Control, javafxpackager, jarsigner, jstatd, visualvm, etc. Finally they can choose to tests each build on each platform they built it for by running the full test suites, but they could also only partially test, as in, run only a subset of the tests, or tests only a subset of the platforms they built it for. You'd want to run tests especially if you did patch the source, to make sure none of your patches introduced bugs, but the build could also have created an issue which tests could uncover, like forgotten to include some important C lib, or resource, or built with wrong optimization options, etc. And last but not least, the license they choose. There's two parts here, the first one is that if they made any changes to the source of their own, their changes might be on their own license, or might not even be open source. That means you might not be able to fork the exact source they used for your own needs, or even get to see the full source they used. The second are the terms of use for each things bundled in the build. Do they let you use the JRE for cloud applications? Can you redistribute it to others? Can you use it for commercial work, etc. Hopefully that better equips you to understand. Most of the companies who make money by building OpenJDK and offering support will probably do a good job at making sure that they backport security fixes as soon as possible, and make sure to always test everything to be sure their backport and custom patches didn't break anything, but they might not always do so for your chosen platform. But as any company who wants to make money, they need to have some of their customers pay them at some point, and that's where licensing and terms of use come in, but more and more they go full open source on their source patches and customization, allow anyone to use things for free in all settings, but offer paid support, though to be sure read their license and terms of use. And if you can't be bothered to read their license or terms of use, that's why people have been recommending AdoptOpenJDK which is now Eclipse Adoptium. Since they're a community effort managed by a non-profit, you can be more confident that their license and terms will be and remain fully open source and free to use in all cases. The downside is that it's a community effort, you don't know if they'll apply security patches quickly, or fully test, etc. And if there's any issue with the build you encounter, there's no real support, no SLA for it, etc. P.S.: There also exists some alternate JDKs, that are not based from the OpenJDK's main source branch, such as OpenJ9, GraalVM, Zing, JamaicaVM, etc. Those should be considered as alternate implementation of Java, they often have very different runtimes and garbage collector and all that, though they can still partially be using some of the stuff from the OpenJDK as well. While all the OpenJDK builds I was talking before always implement everything using the OpenJDK source, all they'd do is add security fixes, bug fixes, retrofit some newer features into older releases, etc. They wouldn't provide alternate implementation of anything the way that GraalVM or OpenJ9, et all, will do.
potamic 5y ago
> and isn't a member of the OpenJDK Vulnerability team Any reasons they are not a member? I would think IBM is trustworthy and mature enough to deal with sensitive security issues.
- didibus 5y ago
  It's not managed by IBM anymore, it's managed by a community of volunteer and the Eclipse foundation. IBM gave it away a whole or back to the community.

by pron 5y ago

ed25519FUUU 5y ago

Interesting about a Adoptium, since that’s the recommended JVM in the article.

mayli 5y ago
I was using adopt jdk since that's much easier to download the jdk (especially jre) for Windows and Linux. The new Adoptium didn't git a jre build, which is sad :(
- flatiron 5y ago
  Honestly if you are using Linux you should be using the distros Java.
  - krzyk 5y ago
    Why? Distros javas are usually way too old to use.
    - flatiron 5y ago
      I use debian on servers and their Jdk has given me 0 issues I develop on arch and they have a great jdk system as well.
    - Seirdy 5y ago
      Almost all distros ship at least openjdk-11, and many including Debian have openjdk-17 now.
      - krzyk 5y ago
        Cool, but did they had 16? Or will they have 18? I use the newest Java version available.
        dtech 5y ago
        In most environments it's better to use a LTS version
        krzyk 5y ago
        In most environments it is better to use latest JDK release not some old one. LTS is associated not with version number but with vendor that provides JDK. So if you don't pay any vendor then you don't have LTS, you just have a number and hope it is in some way better thant any other number - which is not. OpenJDK has no notion of LTS, they release new versions every 6 months, vendors decide which one of those will be supported with fixes, e.g. Azul decided that their JDK 13 and JDK 15 will be supported with fixes for longer their JDK 12 and 14.
- zylepe 5y ago
  The jre is deprecated in favor of jlink, they have an explanation here: https://blog.adoptium.net/2021/10/jlink-to-produce-own-runtime/ https://blog.adoptium.net/2021/10/jlink-to-produce-own-runti...
- Erlangen 5y ago
  SAP provides a friendly interface for both JDK and JRE for Windows and Linux. https://sap.github.io/SapMachine/ https://sap.github.io/SapMachine/

mayli 5y ago

> Recommendation: Do not use Oracle Java SE Development Kit (JDK), unless you know what you are doing.

easton 5y ago

> Eclipse Adoptium, built by IBM, which is the only distribution built by a team that isn't involved with the OpenJDK project Wasn't AdoptOpenJDK the "legit" recommendation a couple years ago? I only heard about all of these other versions sometime later. (Looking again, it looks like the Oracle OpenJDK is shipped in Ubuntu's repos, so maybe I was mistaken).

dtech 5y ago
It was, it recently transferred to Eclipse
didibus 5y ago
> Wasn't AdoptOpenJDK the "legit" recommendation a couple years ago? It was the recommended choice by random internet users who posted blogs, just as is this website, a random website by some random person. The best way for you to understand which JDK to use is to understand superficially what is involved with the source code and the build process between vendors, and their licenses. Source code starts out the exact same, that's why they are all OpenJDK, because they take the source code from the OpenJDK public repository's main branch. From that point on, they can choose to apply source code patches from OpenJDK that have not yet been merged into the main branch, or they could apply their own source code patches. Those patches often will be security fixes, or backported features. Here you have to understand that there is only one main branch of Java. So if you want security fixes or new features but are still on say Java 8, someone has to pull the old commit that was tagged Java 8 and selectively cherry pick a bunch of commits afterwards to apply over it that retrofits all security fixes and possibly a few select new features (like say some performance improvements patches). And if you've ever had to do a cherry pick merge on old code, you know it can be tricky and sometimes there are conflicts and maybe you even need to manually resolve them. And even if they are not grabbing the source from an older tagged version commit, but are grabbing it from the latest tagged commit (so as of this writing Java 17), well it might already be that there are some newer commits that fixed some security bug, or other bug, or improved performance or startup, etc. So in their build of Java 17 they could even decide to apply some of those patches that happened after to the Java 17 latest release. And they might even choose to apply some patches that haven't even made it to the main branch yet, so maybe still have an open PR, or they are the ones patching something of their own. After having grabbed the main source of OpenJDK, and potentially applied some patches to it, they proceed to build it for one or more platforms. In the process of building, they will choose which platform to build for, such as Windows, Linux, MacOS, x64, ARM64, x86, etc. And they will choose what to include in the build, for example should you bundle Java Mission Control, javafxpackager, jarsigner, jstatd, visualvm, etc. Finally they can choose to tests each build on each platform they built it for by running the full test suites, but they could also only partially test, as in, run only a subset of the tests, or tests only a subset of the platforms they built it for. You'd want to run tests especially if you did patch the source, to make sure none of your patches introduced bugs, but the build could also have created an issue which tests could uncover, like forgotten to include some important C lib, or resource, or built with wrong optimization options, etc. And last but not least, the license they choose. There's two parts here, the first one is that if they made any changes to the source of their own, their changes might be on their own license, or might not even be open source. That means you might not be able to fork the exact source they used for your own needs, or even get to see the full source they used. The second are the terms of use for each things bundled in the build. Do they let you use the JRE for cloud applications? Can you redistribute it to others? Can you use it for commercial work, etc. Hopefully that better equips you to understand. Most of the companies who make money by building OpenJDK and offering support will probably do a good job at making sure that they backport security fixes as soon as possible, and make sure to always test everything to be sure their backport and custom patches didn't break anything, but they might not always do so for your chosen platform. But as any company who wants to make money, they need to have some of their customers pay them at some point, and that's where licensing and terms of use come in, but more and more they go full open source on their source patches and customization, allow anyone to use things for free in all settings, but offer paid support, though to be sure read their license and terms of use. And if you can't be bothered to read their license or terms of use, that's why people have been recommending AdoptOpenJDK which is now Eclipse Adoptium. Since they're a community effort managed by a non-profit, you can be more confident that their license and terms will be and remain fully open source and free to use in all cases. The downside is that it's a community effort, you don't know if they'll apply security patches quickly, or fully test, etc. And if there's any issue with the build you encounter, there's no real support, no SLA for it, etc. P.S.: There also exists some alternate JDKs, that are not based from the OpenJDK's main source branch, such as OpenJ9, GraalVM, Zing, JamaicaVM, etc. Those should be considered as alternate implementation of Java, they often have very different runtimes and garbage collector and all that, though they can still partially be using some of the stuff from the OpenJDK as well. While all the OpenJDK builds I was talking before always implement everything using the OpenJDK source, all they'd do is add security fixes, bug fixes, retrofit some newer features into older releases, etc. They wouldn't provide alternate implementation of anything the way that GraalVM or OpenJ9, et all, will do.

potamic 5y ago

> and isn't a member of the OpenJDK Vulnerability team Any reasons they are not a member? I would think IBM is trustworthy and mature enough to deal with sensitive security issues.

didibus 5y ago
It's not managed by IBM anymore, it's managed by a community of volunteer and the Eclipse foundation. IBM gave it away a whole or back to the community.