9 ms·

Amazon Corretto JDK

143 points by gjvc 5y ago

atomicnumber3 5y ago
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. Did I miss anything?
- hn_20591249 5y ago
  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.
  - chrisseaton 5y ago
    > but I can’t see anything compelling that would make me consider this over Adopt All comes down to who do you trust to build and package something correctly?
  - jhugo 5y ago
    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/ https://aws.amazon.com/corretto/faqs/
- heelix 5y ago
  Adopt OpenJDK did have the LTS releases. They rebranded last release - https://adoptium.net 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.
  - jdc 5y ago
    From the Adoptium FAQ: > 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).
    - nomercy400 5y ago
      AdoptOpenJDK used to provide OpenJ9 binaries, are those gone now with Adoptium? I did find some OpenJ9 github site which mentioned they could not provide binaries any more, but I don't really understand why.
      - jdc 5y ago
        Correct, they've dropped OpenJ9 support during the rebranding.
        jdc 5y ago
        As to the reason why, apparently Oracle revoked their TCK[0] license[1]. 0. https://en.wikipedia.org/wiki/Technology_Compatibility_Kit https://en.wikipedia.org/wiki/Technology_Compatibility_Kit 1. https://twitter.com/volker_simonis/status/1052610654669074432 https://twitter.com/volker_simonis/status/105261065466907443... See this Reddit thread for more background: https://old.reddit.com/r/java/comments/l5m3p6/eclipse_to_host_only_tck_compliant_java_se https://old.reddit.com/r/java/comments/l5m3p6/eclipse_to_hos... IBM offers OpenJ9 binaries under the Semaru name here: https://developer.ibm.com/languages/java/semeru-runtimes https://developer.ibm.com/languages/java/semeru-runtimes
  - krzyk 5y ago
    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. I would call it more like Long Term Build.
- syshum 5y ago
  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.
- tyingq 5y ago
  3. Additional pre-built downloads for things like x64/musl, aarch32.
- reidrac 5y ago
  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.
  - capableweb 5y ago
    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.
- miked85 5y ago
  Adopt OpenJDK didn't have TCK compliance - this seems to have changed with the rebranding to adoptium.
- nuerow 5y ago
  > 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. [1] https://whichjdk.com/#amazon-corretto https://whichjdk.com/#amazon-corretto
hn_20591249 5y ago
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.
- Ironlink 5y ago
  According to their user guide, the only patch they have is the branding change: https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/p... I'll keep using the OpenJDK Docker images.
  - iou 5y ago
    They do list the additional patches they do here (for example) https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...
    - iou 5y ago
      I guess v11 is a better link to share there https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
      - geofft 5y ago
        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!
        hueho 5y ago
        In fairness, Java 17 has just been released; it's possible new custom patches will be introduced in future Corretto patch releases. Still, the fact that Corretto 11 had so few backports is encouraging.
rubyist5eva 5y ago
Unless you’re locked into AWS I don’t really see the point of using Corretto when you’re better off (in principle) using Adoptium.
1f60c 5y ago
For an opinionated comparison of various JDKs, see: https://whichjdk.com/ https://whichjdk.com/. (Submission thread: https://news.ycombinator.com/item?id=28820601 https://news.ycombinator.com/item?id=28820601) Disclaimer: no affiliation, just seemed like useful context.
- bombcar 5y ago
  Hey they added Graalvm, which I learned about in the Minecraft world.
  - agluszak 5y ago
    What do you mean in a Minecraft world?
    - chmod775 5y ago
      the Minecraft world, as in the Minecraft community.
      - hugi 5y ago
        Oh. I was really hoping they made a JDK using redstone.
        PedroBatista 5y ago
        Don’t give them ideas.
        vbezhenar 5y ago
        And then run minecraft on top of it? https://xkcd.com/505/ https://xkcd.com/505/
        bombcar 5y ago
        There is the OpenComputers mod https://ocdoc.cil.li/ https://ocdoc.cil.li/ but that’s Lua.
dang 5y ago
One past thread: Corretto – No-cost, multiplatform, developer-preview distribution of OpenJDK - https://news.ycombinator.com/item?id=18449506 https://news.ycombinator.com/item?id=18449506 - Nov 2018 (143 comments)
billfruit 5y ago
Is there any JDK/JRE distribution that bundles in JavaFX?
- filomeno 5y ago
  Here you can see a comparison between some popular JVM distributions and what each one includes. https://www.azul.com/products/core/jdk-comparison-matrix/ https://www.azul.com/products/core/jdk-comparison-matrix/
- oldsecondhand 5y ago
  Oracle JDK does, and I think OpenJDK does as well.
- krzyk 5y ago
  is tbere a reason to bundke it? it is easier to add it as a library.
- gjvc 5y ago
  Azul https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx
robertwt7 5y ago
I’m not a java dev, but my company’s core backend uses java. What’s the main difference between this and java from adoptium? Or even from oracle. I thought they’re all from the same codebase. Is it just support? The versioning and naming of java is very confusing for me
- ttymck 5y ago
  Your comment reminded me a similar discussion was had earlier this week[0]. Coincidentally, the current top comment on this post is whichjdk. [0] https://news.ycombinator.com/item?id=28821316 https://news.ycombinator.com/item?id=28821316
  - robertwt7 5y ago
    Thanks for this!! gave so much insight, gosh I've been using adoptopenJDK for so long because of the blog post recommendation as well lol
- pjmlp 5y ago
  Java is like C and C++, there are plenty of implementations to chose from. Each has their own set of strong points regarding JIT, AOT, GC capabilities, which one to select is usually based on the use case. Unless doing something special, you are pretty safe using a regular OpenJDK distribution.
  - 2ion 5y ago
    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.
didibus 5y ago
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.
simonebrunozzi 5y ago
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]. [0]: https://punchdrink.com/articles/brief-history-italian-caffe-corretto-espresso-coffee/ https://punchdrink.com/articles/brief-history-italian-caffe-...
- elric 5y ago
  > might refer to "Caffè Corretto" And so it does, at least that's what James Gosling said when he announced Corretto at Devoxx back in 2018.
- Stratoscope 5y ago
  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!
  - simonebrunozzi 5y ago
    Donato happens to be one of the best Italian spots in the Bay Area. Good pick!

143 points by gjvc 5y ago

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. Did I miss anything?

hn_20591249 5y ago
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.
- chrisseaton 5y ago
  > but I can’t see anything compelling that would make me consider this over Adopt All comes down to who do you trust to build and package something correctly?
- jhugo 5y ago
  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/ https://aws.amazon.com/corretto/faqs/
heelix 5y ago
Adopt OpenJDK did have the LTS releases. They rebranded last release - https://adoptium.net 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.
- jdc 5y ago
  From the Adoptium FAQ: > 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).
  - nomercy400 5y ago
    AdoptOpenJDK used to provide OpenJ9 binaries, are those gone now with Adoptium? I did find some OpenJ9 github site which mentioned they could not provide binaries any more, but I don't really understand why.
    - jdc 5y ago
      Correct, they've dropped OpenJ9 support during the rebranding.
      - jdc 5y ago
        As to the reason why, apparently Oracle revoked their TCK[0] license[1]. 0. https://en.wikipedia.org/wiki/Technology_Compatibility_Kit https://en.wikipedia.org/wiki/Technology_Compatibility_Kit 1. https://twitter.com/volker_simonis/status/1052610654669074432 https://twitter.com/volker_simonis/status/105261065466907443... See this Reddit thread for more background: https://old.reddit.com/r/java/comments/l5m3p6/eclipse_to_host_only_tck_compliant_java_se https://old.reddit.com/r/java/comments/l5m3p6/eclipse_to_hos... IBM offers OpenJ9 binaries under the Semaru name here: https://developer.ibm.com/languages/java/semeru-runtimes https://developer.ibm.com/languages/java/semeru-runtimes
- krzyk 5y ago
  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. I would call it more like Long Term Build.
syshum 5y ago
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.
tyingq 5y ago
3. Additional pre-built downloads for things like x64/musl, aarch32.
reidrac 5y ago
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.
- capableweb 5y ago
  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.
miked85 5y ago
Adopt OpenJDK didn't have TCK compliance - this seems to have changed with the rebranding to adoptium.
nuerow 5y ago
> 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. [1] https://whichjdk.com/#amazon-corretto https://whichjdk.com/#amazon-corretto

hn_20591249 5y ago

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.

Ironlink 5y ago
According to their user guide, the only patch they have is the branding change: https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/p... I'll keep using the OpenJDK Docker images.
- iou 5y ago
  They do list the additional patches they do here (for example) https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...
  - iou 5y ago
    I guess v11 is a better link to share there https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/patches.html https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
    - geofft 5y ago
      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!
      - hueho 5y ago
        In fairness, Java 17 has just been released; it's possible new custom patches will be introduced in future Corretto patch releases. Still, the fact that Corretto 11 had so few backports is encouraging.

rubyist5eva 5y ago

Unless you’re locked into AWS I don’t really see the point of using Corretto when you’re better off (in principle) using Adoptium.

1f60c 5y ago

For an opinionated comparison of various JDKs, see: https://whichjdk.com/ https://whichjdk.com/. (Submission thread: https://news.ycombinator.com/item?id=28820601 https://news.ycombinator.com/item?id=28820601) Disclaimer: no affiliation, just seemed like useful context.

bombcar 5y ago
Hey they added Graalvm, which I learned about in the Minecraft world.
- agluszak 5y ago
  What do you mean in a Minecraft world?
  - chmod775 5y ago
    the Minecraft world, as in the Minecraft community.
    - hugi 5y ago
      Oh. I was really hoping they made a JDK using redstone.
      - PedroBatista 5y ago
        Don’t give them ideas.
      - vbezhenar 5y ago
        And then run minecraft on top of it? https://xkcd.com/505/ https://xkcd.com/505/
      - bombcar 5y ago
        There is the OpenComputers mod https://ocdoc.cil.li/ https://ocdoc.cil.li/ but that’s Lua.

dang 5y ago

One past thread: Corretto – No-cost, multiplatform, developer-preview distribution of OpenJDK - https://news.ycombinator.com/item?id=18449506 https://news.ycombinator.com/item?id=18449506 - Nov 2018 (143 comments)

billfruit 5y ago

Is there any JDK/JRE distribution that bundles in JavaFX?

filomeno 5y ago
Here you can see a comparison between some popular JVM distributions and what each one includes. https://www.azul.com/products/core/jdk-comparison-matrix/ https://www.azul.com/products/core/jdk-comparison-matrix/
oldsecondhand 5y ago
Oracle JDK does, and I think OpenJDK does as well.
krzyk 5y ago
is tbere a reason to bundke it? it is easier to add it as a library.
gjvc 5y ago
Azul https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx

robertwt7 5y ago

I’m not a java dev, but my company’s core backend uses java. What’s the main difference between this and java from adoptium? Or even from oracle. I thought they’re all from the same codebase. Is it just support? The versioning and naming of java is very confusing for me

ttymck 5y ago
Your comment reminded me a similar discussion was had earlier this week[0]. Coincidentally, the current top comment on this post is whichjdk. [0] https://news.ycombinator.com/item?id=28821316 https://news.ycombinator.com/item?id=28821316
- robertwt7 5y ago
  Thanks for this!! gave so much insight, gosh I've been using adoptopenJDK for so long because of the blog post recommendation as well lol
pjmlp 5y ago
Java is like C and C++, there are plenty of implementations to chose from. Each has their own set of strong points regarding JIT, AOT, GC capabilities, which one to select is usually based on the use case. Unless doing something special, you are pretty safe using a regular OpenJDK distribution.
- 2ion 5y ago
  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.

didibus 5y ago

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.

simonebrunozzi 5y ago

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]. [0]: https://punchdrink.com/articles/brief-history-italian-caffe-corretto-espresso-coffee/ https://punchdrink.com/articles/brief-history-italian-caffe-...

elric 5y ago
> might refer to "Caffè Corretto" And so it does, at least that's what James Gosling said when he announced Corretto at Devoxx back in 2018.
Stratoscope 5y ago
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!
- simonebrunozzi 5y ago
  Donato happens to be one of the best Italian spots in the Bay Area. Good pick!