4 ms·

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.

by xwolfi 5y ago

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 ?

chrisseaton 5y ago
> 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/patches.html 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?
- deleted 5y ago
  [deleted]
- skissane 5y ago
  > 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.
  - CHY872 5y ago
    Is this the same degree of testing you apply each time you upgrade you JDK?
kaba0 5y ago
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.
tablespoon 5y ago
> 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?
- chaostheory 5y ago
  If that’s the case, why migrate back? Especially if Oracle can change the licensing at anytime. They’ve proven themselves to be untrustworthy.
  - tablespoon 5y ago
    > 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.
- CHY872 5y ago
  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.

by xwolfi 5y ago

chrisseaton 5y ago

> 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/patches.html 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?

deleted 5y ago
[deleted]
skissane 5y ago
> 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.
- CHY872 5y ago
  Is this the same degree of testing you apply each time you upgrade you JDK?

kaba0 5y ago

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.

tablespoon 5y ago

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

chaostheory 5y ago
If that’s the case, why migrate back? Especially if Oracle can change the licensing at anytime. They’ve proven themselves to be untrustworthy.
- tablespoon 5y ago
  > 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.
CHY872 5y ago
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.