Amazon has good developers, but the JVM is quite complex and the pool of people who can work on it is pretty rare, I wonder how well they’ll be able to maintain it on their own.
They don't have to fully maintain it on their own. Packaging their own openjdk distribution gives them control over timely targeted bug and security fixes even if they don't have "JVM experts" working on it. I'm not saying they don't have such folks working on it since, well, James Gosling does work there after all along with many other talented folks, but the move makes sense regardless.
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.
>Amazon has good developers, but the JVM is quite complex and the pool of people who can work on it is pretty rare, I wonder how well they’ll be able to maintain it on their own.
Several old (e.g. SUN) Java devs have left Oracle in the last years, so there's that.
We use OpenJDK 8 at Datastreamer as part of our social media and blog/news crawler.
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. ...
The difficulty isn't the new release cadence but upgrading beyond Java 9. It's not as scary as it sounds, and even large complex projects can be upgraded within hours to a couple of weeks. For most projects it's a matter of upgrading dependencies (possibly adding dependencies that have been split off of the JDK) and fixing the command line. I would say that the main barrier is if a dependency does not yet work with 9+. Most popular Java libraries do support 9+, but some don't yet and will soon (e.g. Spark).
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)
This looks interesting, however I can't agree that 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).
"This initial release is a developer preview release for testing and validation purposes."
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.
Quite a number of software houses use pre-alpha-preview betas in production. I’m not sure what motivates them, my theory is that upgrading everything bi-weekly is great busywork for a startup with few users and little traction.
Lack of long-time support commitment. A lot of java users want to hear someone say "we'll push updates for any and all CVEs for the next forty-two years, and that's a promise".
They may not actually install those updates, but they want to hear someone say that they will exist.
Oracle's offering involves paying Oracle money and getting regular phone calls from the Oracle sales department, which I have heard described in colourful ways.
Oracle has/had "value based pricing" for larger contracts
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.
Edit:
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"
SAP: "You are a manufacturing company and will use SAP like this"
Customer: Next...
Obviously, there was more to both conversations - but these are reasonable summaries based upon my dubious memories.
That's how B2B sales work - the salesman works on how much the customer is willing to pay, then discounts the product down to the point the customer will pay, and the checks that isn't below cost of goods.
Or for less than $25 per core, per month. Or clarity on what to do for a 1 VCPU license (1/2 a core). Or how to pay for licenses on ephemeral elastic servers.
OpenJDK is the most "official" Java out there. Oracle develops OpenJDK, and as of JDK 11 all previously commercial features of Oracle JDK have been contributed to OpenJDK, so that now Oracle JDK and OpenJDK are essentially identical[1]
Holding Accountable means those PHBs should buy a commercially supported Open JDK. Just as you can buy commercially supported Linux even though Linux is open source.
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.
I have not used Java in many years now, but I'm curious if anyone has anecdotal experience using OpenJDK in production? Performance vs Oracle Java, bugs/ idiosyncrasies due to internal API differences, etc?
We've been using OpenJDK in production since Java 7 without issue. Since Java 8, Oracle JDK has been built from OpenJDK with a couple of proprietary editions (Java Flight Recorder, SNMP support, different font rendering etc.).
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.
As of JDK 11, there is feature parity between OpenJDK and Oracle JDK, which is the JDK that most people used until now. In JDK 8, the Oracle version had several closed source additional features (such as Java Flight Recorder and the Z garbage collector). Also, implementations of things like graphics rendering used to be different in Oracle JDK 8 and earlier. That's no longer the case. Oracle JDK and OpenJDK should be drop-in replacements for each other as of JDK 11.
Most of those features are only relevant for UI stuff and even then you are unlikely to notice the difference since openjdk would include implementations of anything even remotely relevant. Unless you know you need this, you can safely assume you don't.
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.
Correct. But the chances that you're using any of those features is extremely low.
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.
In our spot tests, we have not seen any performance difference or idiosyncratic behavior. Today, their differences seem more about licensing and support, and less about technology.
Used OpenJDK in production for years. Never seen any issues or bugs. And with the changes in the OracleJDK license going forward we are essentially forced to use OpenJDK.
Cool thanks for posting that link. Quickly looking through the commits. It looks like it was forked off the official JDK 8 a few months ago. Since then, Amazon has been busy with mostly backporting fixes from later versions of the JDK.
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.
Have you used it? Maybe you'd be less surprised :D
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.
You can use Jenkins for closed source. And if you've found a way to display HTML reports (unit tests, coverage, etc) using CodePipeline and IAM but without a hacky Lambda to proxy it from S3 with auth, I'd also love to know. But as is, I believe the offerings are inferior to open source tooling, and don't promote code quality.
It’s just product and amazon didn’t even dogfood internal with it. The internal tools I heard was the best years ago until google hired the original amazon tooling people and so google is the best now
This is good news for Groovy developers since the Groovy project seems to have run into significant roadblocks with migrating to Java 9+. I'd recommend most other developers on the JVM rip that bandaid off now and get onto Java 11 though, because migrating is not going to get any cheaper or easier.
The roadblocks for Apache Groovy migrating to version 3 are imposed by Groovy's backers themselves. They want to keep it as is for as long as possible to keep Gradle users hooked. If a non-compatible Groovy 3.0 comes out, then Gradle users would more likely upgrade from Groovy 2.x to Kotlin instead of to Groovy 3.0 for their build scripting language. The ASF Groovy project managers want to keep their consulting-and-conferences gravy train running for as long as they can.
Given that Corretto is in production at Amazon today could this by default become the most popular (by production instances) JVM? Let's say Corretto becomes the default in BeanStalk, Lambda, and maybe some popular AMI's. Would that be enough?
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.
I suspect it already is in use in Lambda, an AWS rep mentioned something about them using a custom JVM internally for Lambdas when they gave a talk at our company recently, so this is probably that.
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.
If I want a free LTS supported OpenJDK build, how does this compare to AdoptOpenJDK? Which one is likely to "win" as the de facto standard JDK build used by most of the community?
AdoptOpenJDK is the much larger project with broad community backing (We even have Amazon contribute) from IBM, Red Hat, Azul, Ocado, Microsoft etc. It's got a fully open and auditable build and test pipeline and supports a massive number of platforms (arm32/64, AIX, s390, Mac, Windows, Linux x86, PPC etc) and versions (8, 9, 10, 11, amber, 12 beta et al). We've already had over 2M downloads and are definitely in production in a lot of places.
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.
AdoptOpenJDK is at a bit of a disadvantage because it doesn't currently have permission and/or access to the TCK for Java SE so is unable to certify their builds (https://adoptopenjdk.net/support.html#jck). This won't matter for many people but some enterprises will no doubt require it.
As of the latest version of Java, OpenJDK is equivalent to Oracle JDK, and they'll release new versions every 6 month. However, there won't be any security updates or bug fixes to OpenJDK versions from Oracle after 6 months. There's a few groups that plan on maintaining patches beyond that period, but most options involve paying someone (including Oracle).
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.
Does anybody know how good internal OpenJDK in Ubuntu will be supported by Canonical? Somehow I could not find any information about real support in the future. I heard of commitments from and for RedHat though.
I'm sure Corretto will be at some time also available for Ubuntu.
It's likely just the work that Debian does. OpenJDK upstream will always have their repository available, it's just that Oracle is paywalling binary builds after 6 months.
Debian builds from source and is unaffected by the binary paywall.
It's a bit sad that they don't even package it in Amazon Linux's repos. In my eyes that's just building trust on one end and demolishing it on the other.
>At which point will they add their proprietary extensions? Am I the only one fearing this?
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.
Yes, but it's really GPLv2 with the classpath exception [1] which makes it similar to the LGPLv2. Amazon's OpenJDK still has to be GPL. However, software using the OpenJDK can be licensed however you want (because of the classpath exception) [2].
Well Harmony was a JDK released under a more permissive license (Apache) but it has been discontinued. Moreso, unless you want to deal with being sued by Oracle and proving in court that your use of the JDK APIs are fair use (like Google had to do for Android), you really want to use something that is derived from OpenJDK, and thus GPL. So a more permissive implementation isn't likely to ever exist due to the legal liabilities.
I'll take names over alphabet soup. My EBS EC2 machines are not playing nicely with ELB (but my EFS ones are), I think it might be to do with EMR, or maybe EKS.
You could always say: "My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."
No soup.
You nailed it, I hate the tendency of english speakers, specially in tech, to use nonsense acronyms when it would be much easier and understandable to use the word itself, or at least part of it.
"My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."
"My elastic services are not working. Cloud compute machines..."
The problem is partly that AWS—sorry, Amazon Web Services—refer to their products like this in all their documentation and marketing. Using acronyms is great for brevity in communicating within closed environments (we use our own acronyms within our own office to refer to many things, including clients), but if you're product names so long-winded in the first place that you're acyronymizing them all publicly in your own materials you have a problem.
No way engineers will ever do this. We're far to use to TLAs and also, it's way too long. Having a simple, metaphorical brand name allows you to then build on top of that. Can you imagine if Java had instead been called WriteOnceRunAnywhereC++Alternate instead of java? Then, we'd have the writeoncerunanywhereC++alternate Virtual Machine
Within reason, you are actually allowed to use someone else's trademark for something like this provided your own trademark is the more prominent. So something like "Amazon Distribution for Java" would be fine.
It's like they're trying to add an extra layer of stuff that must be learnt in order to use AWS. I have to wonder if it's intended to gear them toward being able to create AWS-specific exams & certifications.
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.
I find that the structure of their documentation could use some work, but the actual language to be fairly good. And by good, I mean less bad when contrasted with most documentation.
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 doesn’t matter when you have this many products. if you know the product, you will find or learn the name. if you don’t know the product, the name doesn’t matter
I'd argue it matters more when you have that many products because it takes a greater amount of mental mind games to remember what all the arbitrary names and acronyms refer to in terms of real world services.
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]?"
You can get Open JDK from any of the following places on them intarweb tubes, and they don't seem to fracture the ecosystem. Linux is available from many places, it may seem fractured, yet Linux seems to be taking over the world. Even Microsoft now "loves" Linux.
Hopefully, OpenJDK would be less fractured than Linux. One thing to note, though, is that you can only call your JDK "OpenJDK" if it's a build of the OpenJDK project, with no substantial additions or removal of code[1]. Most free JDKs are, indeed, OpenJDK, with the exception of the JDK based on IBM's OpenJ9 JVM, even though it uses parts of the OpenJDK codebase.
AdoptOpenJDK will be working with Amazon and the other providers to make sure there's some consistency between the binaries, no point in fragmenting all over the place, consumers expect to be able to drop in replacements.
It's already split between Java8 laggards and Java11. Spark for example hasn't been able to upgrade to Java9 due to their use of some Unsafe stuff. Hadoop just upgraded from 7 to 8 last year.
The list of specific patches applied is here:
https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...
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.
Amazon has good developers, but the JVM is quite complex and the pool of people who can work on it is pretty rare, I wonder how well they’ll be able to maintain it on their own.
They don't have to fully maintain it on their own. Packaging their own openjdk distribution gives them control over timely targeted bug and security fixes even if they don't have "JVM experts" working on it. I'm not saying they don't have such folks working on it since, well, James Gosling does work there after all along with many other talented folks, but the move makes sense regardless.
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.
Probably pretty OK considering James Gosling (founder and lead designer of Java) now works for AWS: https://en.wikipedia.org/wiki/James_Gosling
I imagine having James Gosling on staff will help quite a bit: https://en.wikipedia.org/wiki/James_Gosling
Amazon has loads of money. Presumably if they care about this, they'll pay whatever's necessary to hire the developers they need.
And would still be cheaper than paying Oracle.
I imagine they use it heavily internally, and already have people working on it, so it was just a matter of making it externally available.
>Amazon has good developers, but the JVM is quite complex and the pool of people who can work on it is pretty rare, I wonder how well they’ll be able to maintain it on their own.
Several old (e.g. SUN) Java devs have left Oracle in the last years, so there's that.
Many ex Sun engineers went to AWS much earlier than that.
We use OpenJDK 8 at Datastreamer as part of our social media and blog/news crawler.
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. ...
As of JDK 11, all commercial Oracle JDK features, including low-overhead profiler (Java Flight Recorder), are part of OpenJDK.[1]
[1]: https://blogs.oracle.com/java-platform-group/oracle-jdk-rele...
Yeah.. I'm really excited about that but we're not ready to move to OpenJDK 11... it's a crap shoot with the new JVMs and the forced upgrades IMO.
The difficulty isn't the new release cadence but upgrading beyond Java 9. It's not as scary as it sounds, and even large complex projects can be upgraded within hours to a couple of weeks. For most projects it's a matter of upgrading dependencies (possibly adding dependencies that have been split off of the JDK) and fixing the command line. I would say that the main barrier is if a dependency does not yet work with 9+. Most popular Java libraries do support 9+, but some don't yet and will soon (e.g. Spark).
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)
We do exactly this!
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)
This looks interesting, however I can't agree that 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).
"This initial release is a developer preview release for testing and validation purposes."
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.
Ok, we'll s/production-ready/developer-preview/ the above.
AWS customers are mostly developers and the preview release allows AWS to obtain feedback, and validation from those developers.
Quite a number of software houses use pre-alpha-preview betas in production. I’m not sure what motivates them, my theory is that upgrading everything bi-weekly is great busywork for a startup with few users and little traction.
That theory is not only derisive but incorrect. There is always plenty of non-busy work to be done at a startup, even one with few users or traction.
I think the idea is that it will be.
The posted URL goes to the French version of the page.
This is the primary URL: https://aws.amazon.com/corretto/
I am getting the text in English using the /fr/ url with a French locale on my browser.
the text is english only anyway
Legitimate question: what is keeping stock OpenJDK from being considered "production-ready" as it is?
Lack of long-time support commitment. A lot of java users want to hear someone say "we'll push updates for any and all CVEs for the next forty-two years, and that's a promise".
They may not actually install those updates, but they want to hear someone say that they will exist.
So same as rhel openjdk (https://access.redhat.com/articles/1299013) ?
> Are the binary plugs that Oracle did not release the source supported?
Are the articles that Red Had publishes ever proof read?
> Red Had
:)
I think there's a law about this happening...
But isn't it exactly what Oracle offers? For the money, of course.
Oracle's offering involves paying Oracle money and getting regular phone calls from the Oracle sales department, which I have heard described in colourful ways.
Oracle has/had "value based pricing" for larger contracts
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.
Edit:
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"
SAP: "You are a manufacturing company and will use SAP like this"
Customer: Next...
Obviously, there was more to both conversations - but these are reasonable summaries based upon my dubious memories.
That's how B2B sales work - the salesman works on how much the customer is willing to pay, then discounts the product down to the point the customer will pay, and the checks that isn't below cost of goods.
> But isn't it exactly what Oracle offers? For the money, of course.
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.
Well, we want that for free, of course.
Or for less than $25 per core, per month. Or clarity on what to do for a 1 VCPU license (1/2 a core). Or how to pay for licenses on ephemeral elastic servers.
OpenJDK is the most "official" Java out there. Oracle develops OpenJDK, and as of JDK 11 all previously commercial features of Oracle JDK have been contributed to OpenJDK, so that now Oracle JDK and OpenJDK are essentially identical[1]
[1]: https://blogs.oracle.com/java-platform-group/oracle-jdk-rele...
Nothing, the big thing here is the long-term support. Multi-platform and production-ready are practically a given for any OpenJDK distro.
I don't qualify to answer this... But most enterprises want someone to hold accountable in case of any catastrophic failures.
Holding Accountable means those PHBs should buy a commercially supported Open JDK. Just as you can buy commercially supported Linux even though Linux is open source.
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.
Agree, according to Oracle's new release cadence every major version is "production ready", just that every sixth release is considered for LTS.
Lack of LTS and commercial support most probably.
See this link for context: https://jaxenter.com/end-life-comes-early-jdk-8-140824.html
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.
And also perhaps a rising desire at Amazon to take Oracle down a few notches, as also seen in the recent “uh huh, keep talking Larry” announcements? EG: https://www.theregister.co.uk/2018/11/12/stay_classy_jassy_g...
And perhaps also a desire to maintain parity with Azure since they announced Java LTS support via Azul for their customers a couple months ago (https://azure.microsoft.com/en-ca/blog/microsoft-and-azul-sy...).
OpenJDK 9 and OpenJDK 10 missed several root certificates in its truststore.
Yes! It took me a while to track this down. They weren't really even included until OpenJDK 10. 11 is better but still missing some certificates.
I have not used Java in many years now, but I'm curious if anyone has anecdotal experience using OpenJDK in production? Performance vs Oracle Java, bugs/ idiosyncrasies due to internal API differences, etc?
We've been using OpenJDK in production since Java 7 without issue. Since Java 8, Oracle JDK has been built from OpenJDK with a couple of proprietary editions (Java Flight Recorder, SNMP support, different font rendering etc.).
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.
As of JDK 11, there is feature parity between OpenJDK and Oracle JDK, which is the JDK that most people used until now. In JDK 8, the Oracle version had several closed source additional features (such as Java Flight Recorder and the Z garbage collector). Also, implementations of things like graphics rendering used to be different in Oracle JDK 8 and earlier. That's no longer the case. Oracle JDK and OpenJDK should be drop-in replacements for each other as of JDK 11.
Amazon's OpenJDK is 1.8.0 which is JDK8, so it still 'misses' those Oracle's closed features?
Most of those features are only relevant for UI stuff and even then you are unlikely to notice the difference since openjdk would include implementations of anything even remotely relevant. Unless you know you need this, you can safely assume you don't.
Here's a good stackoverflow post on the topic (note this is about openjdk 7). Things have only improved since then.
https://stackoverflow.com/questions/11547458/what-is-the-dif...
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.
Correct. But the chances that you're using any of those features is extremely low.
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.
James Gosling, says that Amazon uses Corretto in production...which is OpenJDK. So most of AWS/Amazon uses that.
In our spot tests, we have not seen any performance difference or idiosyncratic behavior. Today, their differences seem more about licensing and support, and less about technology.
Opening this up to the world should be not so subtle hint to answer your question with real world experience.
Used OpenJDK in production for years. Never seen any issues or bugs. And with the changes in the OracleJDK license going forward we are essentially forced to use OpenJDK.
The repo is on Github:
https://github.com/corretto
Cool thanks for posting that link. Quickly looking through the commits. It looks like it was forked off the official JDK 8 a few months ago. Since then, Amazon has been busy with mostly backporting fixes from later versions of the JDK.
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.
Wow genuinely surprised that AWS is not using CodeCommit
Have you used it? Maybe you'd be less surprised :D
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.
I have and yes, I'm not surprised :P
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.
> I honestly don't know who they built those services for, but I'll take Travis CI or Jenkins over those services any day.
People who aren't developing open source software and people who want integrated IAM, generally. Git repos having ARNs is pretty neat
You can use Jenkins for closed source. And if you've found a way to display HTML reports (unit tests, coverage, etc) using CodePipeline and IAM but without a hacky Lambda to proxy it from S3 with auth, I'd also love to know. But as is, I believe the offerings are inferior to open source tooling, and don't promote code quality.
It’s just product and amazon didn’t even dogfood internal with it. The internal tools I heard was the best years ago until google hired the original amazon tooling people and so google is the best now
This is good news for Groovy developers since the Groovy project seems to have run into significant roadblocks with migrating to Java 9+. I'd recommend most other developers on the JVM rip that bandaid off now and get onto Java 11 though, because migrating is not going to get any cheaper or easier.
The roadblocks for Apache Groovy migrating to version 3 are imposed by Groovy's backers themselves. They want to keep it as is for as long as possible to keep Gradle users hooked. If a non-compatible Groovy 3.0 comes out, then Gradle users would more likely upgrade from Groovy 2.x to Kotlin instead of to Groovy 3.0 for their build scripting language. The ASF Groovy project managers want to keep their consulting-and-conferences gravy train running for as long as they can.
This is about Amazon removing a revenue stream from Oracle. Amazon also announced a few days ago that they were removing Oracle products from AWS.
Expect an article by Ben Thompson on stratechery.com in the next week.
Amazon is moving their own systems off Oracle; I don't see anything in those stories about Amazon ending AWS customers' Oracle deployments.
Oh, I misunderstood. Thanks for the correction.
Edit:
They are encouraging their customs to migrate though: https://news.ycombinator.com/item?id=18451204 "Best practices for migrating an Oracle database to Amazon PostgreSQL"
To be fair I trust Amazon just about as much as I trust Oracle.
A long time ago I was looking into the cost of Oracle for a company and trying to compare it to Sql Server.
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.
You must not have been a big Oracle customer =)
Given that Corretto is in production at Amazon today could this by default become the most popular (by production instances) JVM? Let's say Corretto becomes the default in BeanStalk, Lambda, and maybe some popular AMI's. Would that be enough?
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.
I suspect it already is in use in Lambda, an AWS rep mentioned something about them using a custom JVM internally for Lambdas when they gave a talk at our company recently, so this is probably that.
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.
> Let's say sometime next year some performance benchmarks come out and Corretto is in fact faster than Oracle's JVM.
What tricks do you think they've got up their sleeve to make it faster?
If I want a free LTS supported OpenJDK build, how does this compare to AdoptOpenJDK? Which one is likely to "win" as the de facto standard JDK build used by most of the community?
AdoptOpenJDK is the much larger project with broad community backing (We even have Amazon contribute) from IBM, Red Hat, Azul, Ocado, Microsoft etc. It's got a fully open and auditable build and test pipeline and supports a massive number of platforms (arm32/64, AIX, s390, Mac, Windows, Linux x86, PPC etc) and versions (8, 9, 10, 11, amber, 12 beta et al). We've already had over 2M downloads and are definitely in production in a lot of places.
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.
AdoptOpenJDK is at a bit of a disadvantage because it doesn't currently have permission and/or access to the TCK for Java SE so is unable to certify their builds (https://adoptopenjdk.net/support.html#jck). This won't matter for many people but some enterprises will no doubt require it.
You mean they announced a five-year supported LTS after Oracle once again told the world they want money for their LTS version? Ouch.
It was kind of nice to have Gosling announce it though.
can i get an eli5 on why we care about this? why not contribute to openjdk? why do we need another flavor?
As of the latest version of Java, OpenJDK is equivalent to Oracle JDK, and they'll release new versions every 6 month. However, there won't be any security updates or bug fixes to OpenJDK versions from Oracle after 6 months. There's a few groups that plan on maintaining patches beyond that period, but most options involve paying someone (including Oracle).
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.
thank you. makes more sense now. much appreciated.
It is openjdk. Amazon intends to package it nicely and support their releases with backports for security fixes.
Does anybody know how good internal OpenJDK in Ubuntu will be supported by Canonical? Somehow I could not find any information about real support in the future. I heard of commitments from and for RedHat though.
I'm sure Corretto will be at some time also available for Ubuntu.
It's likely just the work that Debian does. OpenJDK upstream will always have their repository available, it's just that Oracle is paywalling binary builds after 6 months.
Debian builds from source and is unaffected by the binary paywall.
It's a bit sad that they don't even package it in Amazon Linux's repos. In my eyes that's just building trust on one end and demolishing it on the other.
> Amazon Corretto 8 is in Preview
Probably a good reason to keep it out of the repos
I'd bet it's a matter of time - once they see it mature and/or requested enough I am sure it will end up there.
At which point will they add their proprietary extensions? Am I the only one fearing this? I wouldn't want to depend on a business like Amazon.
>At which point will they add their proprietary extensions? Am I the only one fearing this?
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.
Oracle always has proprietary parts in the JDK and that was no problem for people.
I don't really "get" software licensing but are they bound to GPL because OpenJDK is GPL? Does anyone make a more permissive JDK?
Yes, but it's really GPLv2 with the classpath exception [1] which makes it similar to the LGPLv2. Amazon's OpenJDK still has to be GPL. However, software using the OpenJDK can be licensed however you want (because of the classpath exception) [2].
[1]: https://openjdk.java.net/legal/gplv2+ce.html
[2]: https://softwareengineering.stackexchange.com/q/119436/69573
Well Harmony was a JDK released under a more permissive license (Apache) but it has been discontinued. Moreso, unless you want to deal with being sued by Oracle and proving in court that your use of the JDK APIs are fair use (like Google had to do for Android), you really want to use something that is derived from OpenJDK, and thus GPL. So a more permissive implementation isn't likely to ever exist due to the legal liabilities.
Does anyone know if this Amazon OpenJDK includes a Windows 32-bit version? I can't find any mention of this in the docs.
They don't - Your best bet is probably Azul https://www.azul.com/downloads/zulu/zulu-windows/
Or AdoptOpenjDK https://www.adoptopenjdk.net
> Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit
I really, really wish AWS would start using practical/self-explanatory names for their products.
Well, it's corrected coffee, which matches their intention and general java/beans/jar theme. I kinda like it.
https://en.wikipedia.org/wiki/Caff%C3%A8_corretto
TIL you 'correct' coffee by adding alcohol.
I'll take names over alphabet soup. My EBS EC2 machines are not playing nicely with ELB (but my EFS ones are), I think it might be to do with EMR, or maybe EKS.
You could always say: "My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service." No soup.
You nailed it, I hate the tendency of english speakers, specially in tech, to use nonsense acronyms when it would be much easier and understandable to use the word itself, or at least part of it.
It feels like English should have a provision to factor out the word "elastic" in this case.
Just assume every word in the sentence is elastic.
"My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."
"My elastic services are not working. Cloud compute machines..."
> No soup.
Yeah, what you did is more like a porridge that makes you choke.
The problem is partly that AWS—sorry, Amazon Web Services—refer to their products like this in all their documentation and marketing. Using acronyms is great for brevity in communicating within closed environments (we use our own acronyms within our own office to refer to many things, including clients), but if you're product names so long-winded in the first place that you're acyronymizing them all publicly in your own materials you have a problem.
No way engineers will ever do this. We're far to use to TLAs and also, it's way too long. Having a simple, metaphorical brand name allows you to then build on top of that. Can you imagine if Java had instead been called WriteOnceRunAnywhereC++Alternate instead of java? Then, we'd have the writeoncerunanywhereC++alternate Virtual Machine
WORAC. I like it.
So much better.
so elastic!
That's a different company!
Everybody loves a good TLA!
I think you need some ECS in that mix as well...
Hmm interestingly they renamed that to Elastic Container Service. It used to be named kinda recursively as EC2 Container Service.
[0] https://aws.amazon.com/ecs/
[1] https://aws.amazon.com/about-aws/whats-new/2014/11/13/introd...
>would start using practical/self-explanatory names for their products
So like "Java" and "Swing"?
I’m honestly surprised they didn’t go with “Simple Java Service”. /s
Edit: Added sarcasm indicator
Probably because they don’t own the trademark on Java.
Within reason, you are actually allowed to use someone else's trademark for something like this provided your own trademark is the more prominent. So something like "Amazon Distribution for Java" would be fine.
Well, for one it's not a service...
Or something as Simple as Amazon JDK.
Unless JDK is trademarked to death by Oracle...
Funny, because I can rarely remember GCP's services yet AWS' I don't forget.
Speaking of, CoveffeJDK hasn't been taken yet.
I think you mean CovfefeJDK.
haha. Thanks
It's like they're trying to add an extra layer of stuff that must be learnt in order to use AWS. I have to wonder if it's intended to gear them toward being able to create AWS-specific exams & certifications.
I'd settle for properly written documentation.
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.
I find that the structure of their documentation could use some work, but the actual language to be fairly good. And by good, I mean less bad when contrasted with most documentation.
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 doesn’t matter when you have this many products. if you know the product, you will find or learn the name. if you don’t know the product, the name doesn’t matter
I'd argue it matters more when you have that many products because it takes a greater amount of mental mind games to remember what all the arbitrary names and acronyms refer to in terms of real world services.
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]?"
I wonder if it works well on Windows XP 32-bit.
It doesn’t, and neither should you.
Oracle JDK works well.
Surely Amazon Corretto is just going to fracture the Java ecosystem?
You can get Open JDK from any of the following places on them intarweb tubes, and they don't seem to fracture the ecosystem. Linux is available from many places, it may seem fractured, yet Linux seems to be taking over the world. Even Microsoft now "loves" Linux.
https://aws.amazon.com/fr/corretto/ https://github.com/corretto
https://adoptopenjdk.net/ https://github.com/AdoptOpenJDK
https://github.com/ojdkbuild/ojdkbuild
http://www.azul.com/downloads/zulu/
https://jdk.java.net/11/
https://developers.redhat.com/products/openjdk/download/
https://github.com/SAP/SapMachine
https://bell-sw.com/java.html
Hopefully, OpenJDK would be less fractured than Linux. One thing to note, though, is that you can only call your JDK "OpenJDK" if it's a build of the OpenJDK project, with no substantial additions or removal of code[1]. Most free JDKs are, indeed, OpenJDK, with the exception of the JDK based on IBM's OpenJ9 JVM, even though it uses parts of the OpenJDK codebase.
[1]: http://openjdk.java.net/legal/openjdk-trademark-notice.html
AdoptOpenJDK will be working with Amazon and the other providers to make sure there's some consistency between the binaries, no point in fragmenting all over the place, consumers expect to be able to drop in replacements.
It's already split between Java8 laggards and Java11. Spark for example hasn't been able to upgrade to Java9 due to their use of some Unsafe stuff. Hadoop just upgraded from 7 to 8 last year.
Unsafe is still accessible even in JDK 11. May require some command-line flags, though.
Java9+ broke some undocumented functionality that Spark, Hadoop, etc. may have been using.