There are packaging differences between various JVMs. Some of these are relatively minor (explicit or optional dependencies on X11 or other libraries), others are a bigger issue (how the Java keystore integrates with paths configured for system certificates).

in just a small project we ran into some odd differences in classpath/path resolution behavior. It wasn't a huge deal (and I'm not sure what we were doing before was "right") but there were definitely a few things we had to track down and fix, even in a "straightforward" project.

It's generally related to the infrastructure. Like migrating Dockerfiles, Jenkins, SonarQube servers.

Why do you say it's exactly the same code ? Any Java developers can remember once in his life when openJDK didn't behave as the Oracle one, so you have to test. It's not the same binary, you remember times it behaved differently, and the client is important = you test once that it starts up at least, no ?

> Why do you say it's exactly the same code ?

Well what do you think the differences in the code are?

For example here's a list of patches that Corretto applies to standard Java 17.

https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/p...

It's uh... empty except they change the brand name!

Some older Java builds do back-port a tiny number of fixes early. But why would you use an old version?

> you test once that it starts up at least, no ?

How does that end up taking a significant amount of time and money?

> Well what do you think the differences in the code are?

JDK-8210483 was a regression bug, you pass javac certain Java code which it handled fine in JDK 10 and earlier, in JDK 11 javac would crash with an assertion failure. Oracle fixed this in JDK 12 then backported it to JDK 11; the backport made it in to Oracle JDK 11.0.3, but missed AdoptOpenJDK 11.0.3 and wasn't in AdoptOpenJDK until 11.0.4.

I suppose this is a relatively rare scenario, but due to that bug we could not compile one of our internal apps with AdoptOpenJDK until 11.0.4 came out, whereas Oracle JDK 11.0.3 would compile it fine.

Even though that was a couple of years ago now, I'm still not going to assume that an Oracle JDK build and a third-party JDK build are going to have the exact same set of bugfixes, even if they have the same version number. This is why I think it is important to thoroughly test any migration between different vendor JDK builds before deploying it to production, even if in theory they are supposed to be identical. And even though that testing may be a relatively small amount of work for any given app/microservice/etc, multiply that across dozens or even hundreds of them and it all starts to add up.

Is this the same degree of testing you apply each time you upgrade you JDK?

It may have happened 10 years ago, but OracleJDK is explicitly built on top of OpenJDK for ages now with their few, mostly cosmetic changes.

> Why do you say it's exactly the same code ? Any Java developers can remember once in his life when openJDK didn't behave as the Oracle one, so you have to test.

In the past, definitely. But aren't all recent Oracle JDKs just OpenJDK builds?

There are some differences that each of the vendors adds in or removed. For example… Oracle Java does not include Shenandoah GC but all of the other distributions do. Azul Zulu Java 8 backported Java 11’s JFR while Oracle that code is behind the commercial flag.

If that’s the case, why migrate back? Especially if Oracle can change the licensing at anytime. They’ve proven themselves to be untrustworthy.

> If that’s the case, why migrate back? Especially if Oracle can change the licensing at anytime. They’ve proven themselves to be untrustworthy.

I don't think you would. I was trying to address incompatibility fears as a reason not to move off of it.