I work at Oracle on OpenJDK (but I speak only for myself):

1. OpenJDK is the name of the one and only Java implementation by Oracle (other companies contribute, but Oracle does ~90% of the work); all OpenJDK distributions -- from Amazon's through Microsoft's to Azul's Zulu -- are licensed to you by Oracle (read the license); and if you report to Amazon about a big in Corretto (their OpenJDK distribution), most of the time they'll forward it to us at Oracle to fix, because we're the ones actually developing the thing. So if you want to avoid anything that touches Oracle, OpenJDK is what you should avoid as that is the name of Oracle's implementation (look at the logo! https://openjdk.java.net/). But the "licensing mess" is Oracle open sourcing the entire JDK for the first time in Java's history, and using the name Oracle JDK as the name for their support subscription; if you don't want support, download the JDK from Oracle from http://jdk.java.net/, which, unlike all JDKs prior to 11 is actually completely free. The only licensing difference is that whereas the JDK used to be part open and part proprietary, part free and part paid, it is now 100% open and free. Oracle sells you support, or you can buy it from other companies that also offer support.

However, if you're on 8, your licensing situation is more problematic. Like all JDKs past their end-of-public-updates, you now have to pay for support, or use a free OpenJDK 8u build which 1. only contains backported patches that don't cover the entire JDK and 2. predates the full open-sourcing, so isn't identical to the old Oracle JDK. So not only is the license for versions past 11 better than ever in Java's history, the licensing situation for 8 is not that good because 8 is well past its free support period. Licensing alone is a reason to update.

2. There is no JRE anymore because there are no Applets and no Web Start, and so the model of a centralised runtime is not needed and has been replaced by something much better: custom bundled runtimes easily created with jlink. You, as the application's creator now have full control over its Java runtime, and your users don't need to interact with a third party, or even know or care that your application uses Java.

> IMHO, the best approach is to avoid anything Oracle touches and stick to OpenJDK. For a lot of corporate environments, that's anathema though.

I thought that was just the obvious path; why would companies not like it?

Open Jdk tends to create random and strange issues.

At that point you might as well pitch migrating the tech stack to .net

Except that since several releases Oracle Java is basically OpenJDK + Support.

And some of those issues show up when migrating to recent Oracle Java, too.

Depends what you mean by recent.

For me recent means JDK 14 or later.

That would be somewhat odd; isn't Oracle building off the openjdk as well?

And I have trouble crediting the idea that moving to openjdk is anywhere near the effort to move to a completely different language+platform, even if there are differences.

To be fair I haven't seriously touched java in about 4 years. I do remember Android studio explicitly warning users to avoid Open Jdk

My second point was a joke, still I wouldn't be the one to rock the boat. If anything is even slightly off after switching to open JDK you'd need to justify it

> I do remember Android studio explicitly warning users to avoid Open Jdk

Once upon a time maybe, but today:

> A copy of the latest OpenJDK comes bundled with Android Studio 2.2 and higher, and this is the JDK version we recommend you use for your Android projects.

- https://developer.android.com/studio/intro/studio-config#jdk

> If anything is even slightly off after switching to open JDK you'd need to justify it

"We don't have to license it from Oracle" should justify a lot.

I'll admit when I'm wrong. Thanks for the info

In that case why don’t they move to Amazon Corretto or other enterprise OpenJDK distributions?

Sorry but that is the typical FUD regarding Java and Oracle.

OpenJDK and Oracle Java are as different as Red-Hat Fedora and Red-Hat Enterprise Linux.

If you don't want to pay for Red-Hat Enterprise Linux support, just go with Fedora, or any other Linux distribution.

It is exactly the same with Java distributions.

A problem is taking a company's entire Java codebase that's been running on Oracle JRE's, compiled with Oracle JDK's, written to work around Oracle bugs, for a decade, then trying to throw that on OpenJDK JRE's, compiled with OpenJDK JDK's. If it's a huge codebase then performance and runtime errors alone are concerning enough to stay frozen on 8 for as long as possible, without even considering code migration.

> just go with Fedora

I'm not disagreeing with this at all, but I do want to point out this was CentOS a couple months ago!

I'm sure you know exactly what you're talking about... but I can't really imagine what major incompatibilities you're seeing while doing these upgrades. Java is amazingly backwards-compatible in my experience. I don't think I've ever had to change anything during an upgrade, in my entire career, except sometimes a couple of minor things to do with Unsafe. I'd love to hear more and some concrete examples if you're able to.

I have no experience in upgrading Java versions or the corresponding code changes required. I have witnessed runtime differences, related to performance and GC behavior, from Oracle 8 to OpenJDK 8 that were unexpected enough to warrant temporarily sticking with Oracle in exactly one case.

That is eons ago, in Java 8 there were indeed differences between Oracle JDK and OpenJDK, this in no longer true since Java 10, even less so in Java 16.

Now, Java like C or C++, enjoys multiple implementations, so even across OpenJDK, J9, Azul, PTC, Aicas,..., there will be differences.

And that's why you have tests...

Having migrated some respectably sized projects to OpenJDK in my experience it's more work to migrate a codebase to a new Java major version than from Oracle to OpenJDK.

Are you serious? I've seen several large legacy Java applications move to OpenJDK without a problem.

> OpenJDK and Oracle Java are as different as Red-Hat Fedora and Red-Hat Enterprise Linux.

In a comment in another sub-thread you said "Except that since several releases Oracle Java is basically OpenJDK + Support." But that would be more like CentOS and RHEL, not Fedora and RHEL.

Whatever, the point being that since the last couple of releases OpenJDK and Oracle JDK differences are mostly about support, and license of using JFR in production.

IIRC wasn’t there a huge change in how APIs were exposed from 8 to 9 as well?

Yes modules, but all the libraries in the Java eco-system that matter have long supported it, remember we are at Java 16 now.

That’s all well and fine for third party libraries, but less so if you work at some company with some internal framework or whatever using the old system still.

There are also companies still using Red-Hat Enterprise 5 in production with Java 4 (1.4), but I tend to avoid dealing with them as much as possible.