Looks to be mostly or maybe entirely backports.
Good to see another option out there, it will be interesting to see how many of these get folded back into openjdk8 as it transfers maintainership.
At this point it appears to largely be a vote of support for openjdk as the project evolves.
From their announcement:
Amazon has already made several contributions to OpenJDK 8 and we
look forward to working closely with the OpenJDK community on future
enhancements to OpenJDK 8 and 11. We downstream fixes made in OpenJDK, add enhancements based on our own experience and needs, and then produce Corretto builds. In case any upstreaming efforts for such patches is not successful, delayed, or not appropriate for OpenJDK project, we will provide them to our customers for as long as they add value. If an issue is solved a different way in OpenJDK, we will move to that solution as soon as it is safe to do so.
Several old (e.g. SUN) Java devs have left Oracle in the last years, so there's that.
It's pretty solid for production use. We're REALLY production as we've been in business for a decade and burn a ton of CPU indexing web content. Think petabytes... :)
The only time we use the Oracle JDK is to run their profiler which is pretty darn nice. It's runtime and sampling so you can get a nice sample in a production app by just restarting it...
I've never had a problem with an incorrect sample.
What I REALLY want though is continuous profiling where we have profiling data uploaded to the cloud and alerts when we have an app regression automatically and I want to be told WHERE the regression is. ...
Once you're past 9, it's smooth(ish) sailing. The new feature releases are somewhere between the old update releases and the old major releases, but much closer to the former (BTW, there was a "forced" upgrade to the old update releases, too; they weren't supported after a new one was released).
Overall, the rate of expected breakage, if any, should be the same as it was before, but happen more gradually.
(I work on OpenJDK at Oracle, but speak only for myself)
Our startup Opsian (https://www.opsian.com) is a very low overhead continuous profiling service for the JVM.
Our JVM agent sends profiling data from your instances to our cloud environment where it's indexed, aggregated and made available for hotspots/tree/flamegraph reports.
We even have a dedicated report telling you where regressions happen between releases.
(We're actually out at Devoxx 2018 right now doing a talk on why everyone should be doing continuous profiling)
I wish I could always run a profiler continuously on production, but there are some areas where the overhead is just unacceptable (eg. low latency applications for high frequency trading).
Well... that's not really production-ready then, is it? I assume they intend to make it 'production-ready' at some point in the future, but those two statements are directly at odds.
This is the primary URL: https://aws.amazon.com/corretto/
They may not actually install those updates, but they want to hear someone say that they will exist.
Are the articles that Red Had publishes ever proof read?
The discussion goes something like this:
Customer: "How much does this cost?"
Oracle sales: "How much money do you have?"
Now this isn't quite as bad as it sounds (charge based on the value that the new system will bring) but the conversation was definitely a bit uncomfortable..... Oracle was not selected as the vendor.
SAP weren't selected either for different reasons:
SAP: "You are a manufacturing company and will use SAP like this"
Customer: "We see why you might think that but we don't manufacture things"
Obviously, there was more to both conversations - but these are reasonable summaries based upon my dubious memories.
Right. What distinguishes Amazon's offering is that it has that kind of backing at zero cost.
With Oracle, you can have zero cost, or “production-ready” backing, but not both together.
Production Ready is a different thing than commercially supported. Linux is "production ready" even if you get a distribution which is not commercially supported with a contract and agreements on fixing it at 3 AM when it blows up.
Tl;Dr: with Oracle changing the release versioning of Java, LTS releases are now essentially a paid product. If you run a large business with a lot of Java that is now a significant new burden to deal with.
In practice, none of the differences had any impact on our uses.
Since Java 11, Oracle JDK and OpenJDK are the same. Oracle JDK is just a build that's commercially supported by Oracle.
There's a ton of FUD around OpenJDK and has been for years. For a long time many Apache projects recommended Oracle JDK solely on the grounds that they hadn't been tested on OpenJDK by the maintainers.
Here's a good stackoverflow post on the topic (note this is about openjdk 7). Things have only improved since then.
If you are doing any kind of server side deployment, openjdk has been a drop in replacement since the java 7 days. Essentially all linux distributions include it and you have to jump through hoops to get the oracle version.
There are differences between different openjdk builds though. I've ran into issues with certificates a couple of times on Ubuntu. Also they had a strange notion of what is stable and what is not early in the life of java 8. Another issue is the licensing of the test suite. This makes it hard to test your builds. The words certified build, implies that the produced build passes the licensed test suite.
Most of the differences are commercial features you're not allowed to use without a commercial support contract with Oracle. The only other differences are so small you probably wouldn't notice.
It also seems they have licensed oracle's test suite. So, it is supposedly passing that.
So based on the above, this looks like they are serious about LTS and if you are using java 8, this might be a good build to rely on.
If you want open source contributions, AWS' Code* offerings are a terrible choice. For example, AFAIK you still can't display a build status page that people can view without being logged into the AWS console, like Travis CI or AppVeyor. I honestly don't know who they built those services for, but I'll take Travis CI or Jenkins over those services any day.
Similar experience for other build tools tied to IAM. It's not that IAM is bad or anything, but there's always some convoluted way to get git or docker or kubernetes working when it's tied to AWS.
People who aren't developing open source software and people who want integrated IAM, generally. Git repos having ARNs is pretty neat
Expect an article by Ben Thompson on stratechery.com in the next week.
They are encouraging their customs to migrate though:
"Best practices for migrating an Oracle database to Amazon PostgreSQL"
For SQL Server, you just go to the page and the price is right there.
For Oracle, you have to talk to a salesmen. That turned me off from Oracle.
With AWS, I know exactly how much a resource will cost and there are a myriad of ways you can get detailed billing.
Let's say sometime next year some performance benchmarks come out and Corretto is in fact faster than Oracle's JVM. Would people be quick to switch? Would enough people switch? I feel like the Java ecosystem has been at the verge of a "phase shift" for a long time. There's a lot of pent up demand for features and Oracle and the governance process just aren't delivering. So now Amazon steps in and, just think about it, what are the odds this JVM ends up faster, better, and gasp with some new features people want.
As for the default on AMIs, it probably will go that way when OpenJDK 8 support ends next year. They'll have the option of distributing RedHat's OpenJDK build with their patches, or packaging their own. It'll probably be similar to the `mysql` package actually providing MariaDB, and no one will really notice.
I am intrigued if there will be noticable performance improvements. They do mention performance enhancements on the page, but I believe this is more about dealing with Oracle's licensing changes and maintaining support for the LTS releases. But there's plenty of incentive for them to make it better performing than alternatives too.
I expect my company will switch to this because we're already on Amazon Linux 2, and have been struggling to make a decision on how to update the JDK with future releases. But if there are performance improvements, that might push some more AWS users to switch to Amazon Linux over Ubuntu and other distros in EC2.
What tricks do you think they've got up their sleeve to make it faster?
We'll be working with Amazon to make sure there's some consistency between the two, no point in fragmenting.
Corretto is an obvious choice if you're an AWS user, for everything else Adopt is also a decent choice.
It was kind of nice to have Gosling announce it though.
It's mostly just about enterprise distribution, rather than any differences in the JDK. Updating major versions every 6 months is risky, not having security updates is more risky, and no one likes paying money for something that they've been getting for free.
So far this seems like the simplest and cheapest way of getting long term security/bugfix updates for the JDK, especially if you're already running Amazon Linux. We've been evaluating the options in my team recently and hadn't come to a decision beyond "update to Java 11 and see how it goes after that". This pretty much solves our problems.
I would have preferred to see Amazon partnering with Red Hat or other open source groups on maintaining one well supported OpenJDK, but at least as it's all open source, patches should make their way to all versions.
I'm sure Corretto will be at some time also available for Ubuntu.
Debian builds from source and is unaffected by the binary paywall.
Probably a good reason to keep it out of the repos
What? OpenJDK is GPL with a class path exception, so software that runs on it can be licensed however but additions/changes to OpenJDK cannot be kept proprietary. Can you please elaborate what you're afraid of there? It's not as if Amazon is the copyright holder and can thus even offer a dual license.
I really, really wish AWS would start using practical/self-explanatory names for their products.
Just assume every word in the sentence is elastic.
"My elastic services are not working. Cloud compute machines..."
Yeah, what you did is more like a porridge that makes you choke.
So like "Java" and "Swing"?
Edit: Added sarcasm indicator
I'm a long time AWS customer and I love AWS, but to be honest, the documentation is bad. I don't think they understand how to write for developers at all. It feels like they hired an army of Kevin Turvey clones.
To go off on a bit of a tangent, I'd prefer that documentation be split up into two parallel versions that are heavily linked but mostly separate:
- Code examples describing everyday usage
- Detailed API/system descriptions
AWS should do a better job on the former, although that'd be a massive amount of work for them at this point with little payoff. I find that I end up relying much more on Stack Overflow and even code from wrapper libraries to understand how to do relatively uncomplicated things with their API. In general, however, I'd prefer it that all documentation be more the former than the latter. I find that when I'm given everyday examples, that aren't hideously formatted on the webpage, I can get a better understanding much quicker and become far more productive.
Most documentation isn't good at either providing practical examples or actually explaining usage. I feel like there's a missing link between English-majors and software engineering; if there are English-majors who also understand programming, they should be paid handsomely to write documentation. But when do we ever see job postings for specialists in writing documentation? I've never seen such a job title.
It also makes discoverability harder. eg when you're already on AWS and you think "is there a service that does something like [insert problem]?"