Yeah the site is useless. I didn't comment on the last post but to summarize from a JVM/infra guy:
Use a JDK that contains the features you want and is from a vendor that gets access to embargoed Java security updates.
This matters more for pre-Java 11 as certain vendors backport things like Java Mission Control/Flight Recorder and other performance and debugging features to Java 8. Post Java 11 the feature sets of the various vendors are roughly equal with much more minimal diversity.
For the most part they are generally equal. The determining factor depending on your org size might be your capacity to pay for support and your tendency to need that support. My pick is Azul but Coretto or any of the others are fine too.
Try make sure you are at least on Java 11 as the Java 8 -> 9 migration was very hairy due to modules. If you are at least on Java 11 then all future upgrades are likely to be very easy in comparison.
I know, I know, it doesn't really matter, but for the very curious among you, "corretto" might refer to "Caffè Corretto", an Italian flavor of espresso coffee with alcohol added to it.
The origin of "corretto" in that sense are really interesting [0].
Hey, paesano! In an amusing coincidence, I had a delicious Caffè Corretto after dinner at Donato Enoteca in Redwood City last night. They make it with a shot of espresso and a shot of grappa (Italian grape brandy for those unfamiliar with the word). Bracing!
I've peripherally known Corretto is the Amazon distribution of Java (specifically, OpenJDK), but I never really looked up what the difference between, say, the releases from AdoptOpenJDK and Corretto are.
I looked it up, it looks like it's generally:
1. LTS support - adoptopenjdk doesn't do LTS
2. Patches that come from Amazon that are upstreamed to OpenJDK but appear in Corretto first since, you know, that's where Amazon develops them.
Adopt OpenJDK did have the LTS releases. They rebranded last release - https://adoptium.net. The quarterly updates to Java 8, 11, and now 17 are all there, and up till then, been pulling 8/11 from Adopt OpenJDK's site.
All in all, not much different. The last release was a bit of a kerfuffle, as they migrated web sites.
> This is the project and brand name for the binaries that the Eclipse Foundation produces. You can think of these as the successor binaries to AdoptOpenJDK.
The current LTS versions are 8, 11 and 17. Supported platforms include arm32 (Linux), aarch64 (Linux & macOS), x64 (Windows, Alpine & Linux w/ glibc) and x86 (Linux).
LTS means active support (call/email to fix issue), what Adopt does is just builds from branches that receive commits/fixes from other vendors/people.
They don't have TCK, they do their own tests on the builds. But you could probably do such builds yourself, everyone has access to openjdk github repo.
That one HN comment that recommended JDK engines explicitly warned against Eclipse. Not sure if it still applies with the AdoptOpenJDK -> Eclipse migration
My Experience Corretto is easier to deploy on systems that just need the JRE seems to be a more drop in replacement to the old consumer Java8 msi installers, than the OpenJDK "offical" packages which are some what confusing.
IIRC we had to move to Corretto when using AWS CodeBuild, because AWS dropped support of AdoptOpenJDK in their CodeBuild container images.
So basically we use AWS distro to run tests and build our docker images, and those images use AdoptOpenJDK; which is not ideal, but so far we have been OK.
Basically, you moved to Corretto because Amazon forced you to. That's great :)
I think this is a common reason for moving to a particular distribution, but also sad to see. Amazon used to be impartial and independent infrastructure provider but as they ingest more and more software, your infrastructure and software now starts to depend on Amazons software.
> I've peripherally known Corretto is the Amazon distribution of Java (specifically, OpenJDK), but I never really looked up what the difference between, say, the releases from AdoptOpenJDK and Corretto are. (...) Did I miss anything?
According to [1], Amazon Corretor is a OpenJDK build which is:
* maintained by Amazon (back ported bug fixes, patches),
* includes Amazon's custom crypto provider optimized for AWS,
* Optimized builds for Amazon's Linux distro, Amazon Linux 2.
I asked an adjacent question and am also curious, great that they have provided another option for the OpenJDK community but I can’t see anything compelling that would make me consider this over Adopt.
If you are already paying AWS for premium support, one reason to use Corretto rather than Adoptium is that your AWS premium support plan covers Corretto as well.
"If you already have an AWS Support Plan, Corretto is covered on the same basis as all other supported AWS Services and software." https://aws.amazon.com/corretto/faqs/
The best way 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.
Unlike the C/C++ compiler landscape which for industry use cases has a few high profile high quality candidates, and all vendors of these solutions are pretty much guaranteed to employ top level experts to evolve their softwares, the picture with the JDKs is much less clear. Apparently everybody who has some sort of name brand now rolls their own version, and even throughout this thread here there really is no sharp level of distinguishment based on a clear point of comparison between even the most popular contenders.
Looks like muddy waters to me. A shame really, they totally ran the JDK release management into the ground.
Could someone provide a TL;DR on the major patches/benefits that Corretto has over Adopt or other community driven JDK implementations? It is unclear from the documentation but I am assume they have some secret sauce for faster boot for their Firecracker VM instances.
Adoptium is not "community driven" (it's made by IBM), and there is only one OpenJDK implementation, the one led and primarily developed by Oracle, with contributions from other companies. What Amazon or IBM do is build the source and distribute the binaries (look at the licence).
"...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. "
My understanding is that ties between the Eclipse Foundation and IBM are loose enough by now to not call this project an IBM thing. Eclipse did originate at IBM, but that was close to 20 years ago.
That may be so, but >90% of the work on this particular Eclipse project is done by IBM. Just as many companies contribute to OpenJDK but it is primarily an Oracle project, and Oracle does most of the work, Adoptium is an IBM project. That, in itself is not good or bad (although it is somewhat bad because, unlike other JDK distributors, IBM is barely involved with OpenJDK and the IBM team that makes the Adoptium builds is not particularly familiar with OpenJDK), but it is certainly not a "community led" distribution -- it is, de facto, an IBM-led one. It did not start out this way, but it has been this way for several years now (they did the same with https://en.wikipedia.org/wiki/Apache_Harmony).
Are we talking about the (Open)J9 flavor here? It was featured more prominently on the AdoptOpenJDK page, but has now all but disappeared on the Adoptium site. J9 is something that I can definitely associate with IBM, what I'm having a hard time with is connecting the work on HotSpot builds to the company.
I'm talking about the Adoptium (née AdoptOpenJDK) builds, which are made by IBM. IBM aren't involved much with OpenJDK, but they can still run `make` on server farms. Although Eclipse OpenJ9 is yet another IBM project.
I worked at AWS and Corretto came out towards the end of my tenure there. At the time (Java 8), it included in house patches that upstream haven’t or due to politics refused to adopt.
Now that I don’t work at Amazon any more I still advocate for the distribution for the LTS model, and the fact that it contains fixes that are only discovered when running in production at the scale of Amazon and AWS.
Which has been a staple of long-term JVM production guys for a long time. You can use their releases free of licensing but can get commercial support if/when you need it.
You probably shouldn’t. Last I checked the OpenJdk docker images use the Debian builds of OpenJdk and there’s been multiple times where they’ve shipped vulnerable builds. [0] You should probably just use the Zulu builds.
Wow, that's awesome - 8 had a handful of custom patches and some backports, 11 had only backports, and 17 has nothing. This is kind of the best possible story for a distribution fork!
Disclaimer: no affiliation, just seemed like useful context.