Amazon Corretto 18 is now generally available
aws.amazon.com
aws.amazon.com
FAQ: https://aws.amazon.com/corretto/faqs/
Downloads: https://docs.aws.amazon.com/corretto/latest/corretto-18-ug/d...
Q: How is Corretto different from OpenJDK?
A: Corretto is a distribution of Open JDK with patches included by Amazon that are not yet integrated in the corresponding OpenJDK update projects. We focus on patches that improve performance or stability in OpenJDK, chosen based on Amazon's observations running large services.
Q: What kinds of patches does Amazon intend to include in Corretto?
A: Patches will include security fixes, performance enhancements (e.g., speeding up frequently-used functions), garbage collection scheduling, and preventing out-of-memory situations, as well as improved monitoring, reporting, and thread management.
https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...
https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/p...
Edit: While not technically a patch, I should note that they do have different compile options than the Oracle builds. The biggest difference I can think of is Amazon ships with the Shenandoah GC enabled, while Oracle's builds do not.
Change Log for Amazon Corretto 17 https://github.com/corretto/corretto-17/blob/develop/CHANGEL...
Change Log for Amazon Corretto 18 https://github.com/corretto/corretto-18/blob/develop/CHANGEL...
I found it by looking at their changelog for Corretto 11, which includes both their patches and the changes from mainline.
https://github.com/corretto/corretto-11/blob/develop/CHANGEL...
"Amazon Corretto, A Journey into Latency Reduction":
I'm not sure how I never heard about this before now. Is anyone out there using this over other JDKs?
That said, it depends a bit which OS you are on. The Linux distros have gotten a lot better with their OpenJDK support in their package managers. So if I am using a bistro with the OpenJDK version I want, I will use that now.
NEVERTHELESS, software supply chain is important. Whatever JVM one chooses should have a good answer to how they handle it.
We do agree on that. We also agree that Linux distributions & Docker official images have been doing shitty job in the past which is what your article is talking about. Thanks to Gil Tene continuous efforts to raise awareness about this issue, situation has somewhat improved.
My point is that AdoptOpenJDK has been specifically created to tackle those issues. Your initial comment seems very unfair to them and could misguide some people.
Everyone is free to pick the JDK build of their choice. Several projects do a good job at providing quality builds of OpenJDK. Most OpenJDK distributions are upstream first, so the determining factor is the trust you put in their build, test & QA processes. From that point of view and in a long term vision, supporting AdoptOpenJDK / Adoptium Temurin looks like a smart move because their tooling & processes are open source and which keeps the OpenJDK ecosystem in a safe state as it doesn't rely on a few private companies as sole providers for the community. History taught me that over reliance on Amazon or Azul might not be a good idea. Lets thanks them for their contributions, but lets no depend on them without viable alternatives.
Agreed, alas I cannot edit it anymore.
I was wrong in my understanding as to how the 'mystery meat' got into the flow. Having looked at the AdoptOpenJDK repos it's clear they do their work in the open. That's no guarantee, but is the best choice over the long term. And a JVM is a long term thing.
The reason is that we host on AWS Elastic Beanstalk, and this is the Java distribution that is supplied by default on Elastic Beanstalk's Java-based images.
Amazon Corretto is, for us, unremarkable, in a very positive way. Unremarkable in that we never encounter problems with it.
Because oddly enough Beanstalk only supports Corretto 11: https://docs.aws.amazon.com/elasticbeanstalk/latest/platform...
https://docs.aws.amazon.com/corretto/latest/corretto-18-ug/d...
The only major difference is Corretto enables an alternative GC, Shenandoah, which was originally implemented by RedHat. This has been mainlined for a long time now, but Oracle does not ship it. It is available in the Azul and RedHat builds as well.
IntelliJ lets you download + install + switch between JDKS really easily, which I've found indispensable.
As another person commented, the Liberica JDKs with JavaFX built in are my go-to for hobby type coding.
If you don't use brew to install your software, you probably should start doing so.
Windows? Chocolately. https://community.chocolatey.org/packages/openjdk
I thought Azul was a bit more customised around the gc, so not quite the same JVM?
JS/V8 is particularly impressive. I wonder how far we are from the theoretical performance limit on the software side?
I would guess we will eventually see deprecations of warts to improve engine performance further. Or integrated type system etc.
But maybe there are technical reasons why it's not feasible
The thing Dart "fixed" in terms of performance is it forced consistent typing. It removed the ability to add/remove/change fields/methods on an object at runtime. The Achilles' heel of javascript (at least, when I got hype on dart years ago) is how stupidly easy it is to change the memory shape of any object. That means the VM can't generally lay out memory for an object in a compact form. Further, the VM has to do a bunch of checks before it can go down the optimized path (in case assumptions are invalidated).
For a consistent type system, the only check needed is "is this object shaped like I think it should be?" and then you go from there.
I think the most disappointing part of Dart is that all that effort was spent creating a new language when what the browser needed (and still needs) is a new bytecode. I'd love to see WASM reach the point of a universal bytecode but fear that it painted itself into a corner by first targeting memory managed languages.
There are a lot of caveats here. You could potentially claim "minimal gains in peak performance if you can apply adaptive JIT compilation techniques", but even that is stretching it somewhat.
Adaptive JITing comes at a price in terms of warmup, memory usage and implementation complexity. Fixed object shapes help somewhat to reduce the amount of checks needed but they don't take you all the way there. Optimising numerics remains challenging (e.g. think about optimising the case where a field always contains a `double` floating-point value or a field that always contains a 64-bit integer value). Knowing the shape of the container does not yield any information about the shape of elements which implies that some checks have to stay behind in the loops. Yes, monomorphic checks are usually simple (compare+branch) but polymorphic are not. And so on and so forth.
Yes, Dart 1 is easier to compile into efficient code compared to JavaScript. Dart 2 is even easier though - because it is more statically typed.
> but fear that it painted itself into a corner by first targeting memory managed languages.
FWIW WASM GC is coming - and it looks great.
I've not been tuned in. Is there some good forward progress there? It along with threads felt stalled out. I'd love to see GC adopted as that would, IMO, turn WASM into something close to a universal bytecode. It would significantly expand the number of languages that could reasonably target WASM.
Time to work on bringing back java applets ;)
https://www.theregister.com/2022/03/22/oracle_starts_to_incl...
If you're not familiar with O, or wondering why an innocuous statement like the above strikes fear into people, it's not about just licensing Java. It's about their extortionate tactics and how they try to catch you in gray areas due to ambiguous wording in their terms and conditions, and demand fees for violating them.
It is presumably referring to “VirtualBox 6.1.32 Oracle VM VirtualBox Extension Pack”:
> Support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
> The Extension Pack binaries are released under the VirtualBox Personal Use and Evaluation License (PUEL).
The vast majority including I, only ever used guest additions (GPL).
That would not surprise me. Back when we were considering virtualisers many years ago, the issue was one of the reasons² I recommended against vbox despite using it at home - it felt a bit too dark-patterny¹ for my tastes. We went with a VMWare tool instead.
[1] though I'm not sure the term “dark pattern” had been coined, or if it had it was in my vocab, at that point
[2] another being Oracles general behaviour at the time - this was after their purchase of Sun and therefore Virtual Box.
For those asking, it's about the "VitualBox 6.1.32 Oracle VM VirtualBox Extension Pack" - it's free to install but phones home and they reach out after a year or two of use and attempt to coerce you into paying for a license. Just ensure everyone has uninstalled it and tell them to go pound sand.
VirtualBox Extension Pack, on the other hand, provides support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
If you use OracleJDK (which is pretty identical so unless you need support, go with OpenJDK), then you previously had to pay, but Oracle recently made the last version of it free to use. I mean, it really can’t get easier and freer. It is the same model as with Red Hat linux and fedora, hell, it is even more permissive as you can use the latest Red Hat version free of charge until the next one comes around (+1 year)
"Oracle Java Release 17 Is it Free Again?"
https://www.softwareone.com/en/blog/all-articles/2021/09/20/...
The only thing complicated here is that people seem to think that OracleJDK IS OpenJDK, it is not nor has it ever been.
OracleJDK is no different than Azul's JDK. It's a JDK vendored and supported by Oracle.
The long and short answer is, so long as you are using a JDK vendored by your operating system or a docker image that doesn't explicitly say "oracle jdk" you are and continue to be safe. There's no sneak lawyer trap that's going to spring. I've seen these claims ever since oracle bought sun and have yet to see oracle act in bad faith with their sun acquired open source software.
"Java Is Still Free 3.0.0 (Oct 2021)":
https://medium.com/@javachampions/java-is-still-free-3-0-0-o...
It literally says that in the very article you claim to be FUD. Have you even bothered to read it? Because it says everything that you did.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
Oracle has a FAQ here: https://www.oracle.com/java/technologies/javase/jdk-faqs.htm...
It’s also more confusing than you indicate because you are excluding all historical context. The “regular” JDK everyone installed up until Java 8 was the “JDK downloaded from Oracle” and the open source OpenJDK was, for lack of better words, a knock-off with poor compatibility with a lot of enterprise software but used because you couldn’t include JDK in your distro’s package manager (even though it was completely free to use) because the license wasn’t GPL compatible. So everyone that cared about vendor-approved compatibility downloaded “the JDK” from Oracle as a tarball and used that. Those that were running home software could get away with using “apt install openjdk” instead.
After Java 8, Oracle pulled a huge switcheroo and said everyone should use OpenJDK instead, and their licensed customers could use the Oracle-provided JDK instead. They didn’t put it behind a paywall or even login, and left it available for free.
So if you missed the bit about OpenJDK being officially blessed to use or you continued to just go to Oracle.com to download “the JDK” for commercial use, you were now in violation. Some say Oracle licensing is never confusing by accident and the official recommendation to switch to a previously inferior alternative wasn’t a charitable move.
If you don’t know OpenJDK is what you want, you search for “JDK” and the only entity allowed to use the plain “JDK” moniker is Oracle. Even now, just Googling for “download JDK” gives you Oracle’s JDK (that’s twenty years of PageRank and inbound links pointing to what was once a “free” download - there’s no outranking that!) as the first result.
(Given Google’s IP history with Oracle, they should show “Did you mean OpenJDK?” and include those results too :D)
Our usage of Oracle Java 8 is classed as free still, and we pay Azul for the rest of our Java usage. I highly recommend Azul if you are looking for a vendor.
It is incredible how people keep missing the picture about OpenJDK main contributer.
Particularly, that it makes it too easy for end-users to stumble into using components that do not come under its open source licence. This makes it a headache for organisations and users, because it is very difficult for an organisation to police "you can use X, but you musn't pass Y command-line flag that could invoke a non-free part" and other actions that could create a liability for the organisation (and a disciplinary row for the employee)
It's a little like deciding you're going to set up a sweet shop, give out free samples, and lay landmines one foot either side of the entrance.
If they historically used a model more similar to JetBrains or other companies that have a commercial open source product (where the program looks for a licence key in order to activate the non-free features, or where there is a completely separate install process for free and non-free versions) I expect they wouldn't face the same regular criticism. It's the 'Surprise! Lawyers!" aspect that people find stressful and unattractive.
With JDK builds, this separation of free and non-free product is what the community has essentially provided: if you install something like Adoptium Eclipse Temurin, you can be a bit more confident it hasn't bundled non-free programs that could create a financial liability alongside it. You could try to track which Oracle downloads are what, but they've changed their licence from time to time, so some people find it easier simply to differentiate by what organisation provided the packaged JDK.
This is like going for CentOS to work around Red-Hat doing most of the work.