> 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.
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?