6 ms·

>This isn't after 8. Reasonably certain its not before 8 :) I do remember those times tho. When bugs like the jvm exploding doing basic things like adding and

>This isn't after 8. Reasonably certain its not before 8 :) I do remember those times tho. When bugs like the jvm exploding doing basic things like adding and removing items from an arraylist for a prolonged period of time would be fixed in the next point release before anyone really realised - rather than left to people who are too busy fixing their own bugs to notice and replicate, resulting in such bugs hanging round for 2 lts releases and a decade later. >We focus on stability today much more than we did in the 8 timeframe. Couple of thoughts on this. Are those tests really capturing the "jvm explodes after 100 hours" issues, like in that bug report. Or are they just "no new segfaults in this short lived jvm run in a VM that just completely changed the gc again and rewrote a big chunk of the thread handling code", I dont have faith they do simply from burning so much dev time previously to find they werent. But also; it is really nice to see jdk development process stabilise after the terrifying licence changes we got on 8 - Im sailing right now, back in the office soon, however I dont see any adoptium builds for 17, any idea when I can actually check all this myself?

pron 5y ago
> Reasonably certain its not before 8 :) Well, the bug dates at least as far back as 8. > I do remember those times tho. Since you're talking to a member of the team that maintained Java back then, I can tell you that our quality process back then looks like a joke compared to what we have now. Of course, you might have been bit by a problem, but our stability has 100% not gone down (backed by irrefutable data), and most likely has gone up. > Couple of thoughts on this. Are those tests really capturing the "jvm explodes after 100 hours" issues, like in that bug report. Once again, whatever we did 8 years ago, we're much more thorough today. We are not bug free, but we don't have more bugs than before, and we probably have fewer. > But also; it is really nice to see jdk development process stabilise after the terrifying licence changes we got on 8 By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free for the first time in Java's history that happened in JDK 11? Some people were confused when we made Java entirely free and unencumbered, and made OracleJDK the name of our support subscription, so we've changed it a bit now again. But as of JDK 11 -- and unlike any Java version that came before it -- the JDK is completely open. > however I dont see any adoptium builds for 17, any idea when I can actually check all this myself? Adoptium is a project run by an IBM team, and I have no knowledge of their process. Unlike Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon, Adoptium is not involved in OpenJDK and is not a member of the vulnerability group, so their builds usually come after everyone else's because they're less familiar with the OpenJDK project and its process (they're more familiar with OpenJ9). But I'm sure they'll be able to make a build soon enough.
- DarkmSparks 5y ago
  >Adoptium is not involved in OpenJDK They replace adoptOpenJDK https://adoptopenjdk.net/ https://adoptopenjdk.net/ ... >By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free No, I mean https://www.policypak.com/resources/pp-blog/oracle-java-license-change/ https://www.policypak.com/resources/pp-blog/oracle-java-lice... >Once again, whatever we did 8 years ago I didnt (particularily) place any blame. If it wasnt your testing that was catching them early it must have been someone elses. Presumably they left the ecosystem. >the JDK is completely open. But a shadow of its former self. >but we don't have more bugs than before Im really talking about issues related to very long running jvms. The kind of things that would have killed applications like apache tomcat dead. In fact it looks like they use their own jvm build now, I'll give that a go at the same time..... however it looks they they are still really on 8 as well.
  - pron 5y ago
    > They replace adoptOpenJDK https://adoptopenjdk.net/ https://adoptopenjdk.net/ ... Yep, it's the same IBM team, who aren't involved in OpenJDK (and weren't when they were called AdoptOpenJDK). They mostly know OpenJ9. > https://www.policypak.com/resources/pp-blog/oracle-java-lice https://www.policypak.com/resources/pp-blog/oracle-java-lice... Almost everything here is wrong. The prices and licensing terms are very wrong, but, most importantly, what Oracle did was, instead of provide one part-free, part-paid, JDK, we started providing two indentical ones with different licenses: one completely free, and one for support subscribers. > But a shadow of its former self. Actually, it has many more features today than it did back in 8.
- DarkmSparks 5y ago
  Not sure if you'll catch this message any time soon, but: 1. major source of incompatibility was the removal of the ability to cast ClassLoader to a URLClassLoader, fixes for that were relatively extensive but also simple enough to get running in a few days. 2. Not seen any crash reports in the first 24 hours which is a good sign, any that do come up I will forward as bug reports. 3. Perf wise, about equal, memory usage is much better. 4. Thanks for the impetus to give migrating another go.

pron 5y ago

> Reasonably certain its not before 8 :) Well, the bug dates at least as far back as 8. > I do remember those times tho. Since you're talking to a member of the team that maintained Java back then, I can tell you that our quality process back then looks like a joke compared to what we have now. Of course, you might have been bit by a problem, but our stability has 100% not gone down (backed by irrefutable data), and most likely has gone up. > Couple of thoughts on this. Are those tests really capturing the "jvm explodes after 100 hours" issues, like in that bug report. Once again, whatever we did 8 years ago, we're much more thorough today. We are not bug free, but we don't have more bugs than before, and we probably have fewer. > But also; it is really nice to see jdk development process stabilise after the terrifying licence changes we got on 8 By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free for the first time in Java's history that happened in JDK 11? Some people were confused when we made Java entirely free and unencumbered, and made OracleJDK the name of our support subscription, so we've changed it a bit now again. But as of JDK 11 -- and unlike any Java version that came before it -- the JDK is completely open. > however I dont see any adoptium builds for 17, any idea when I can actually check all this myself? Adoptium is a project run by an IBM team, and I have no knowledge of their process. Unlike Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon, Adoptium is not involved in OpenJDK and is not a member of the vulnerability group, so their builds usually come after everyone else's because they're less familiar with the OpenJDK project and its process (they're more familiar with OpenJ9). But I'm sure they'll be able to make a build soon enough.

DarkmSparks 5y ago
>Adoptium is not involved in OpenJDK They replace adoptOpenJDK https://adoptopenjdk.net/ https://adoptopenjdk.net/ ... >By "terrifying license change" you mean the 100% open-sourcing of the JDK, and making it 100% open and free No, I mean https://www.policypak.com/resources/pp-blog/oracle-java-license-change/ https://www.policypak.com/resources/pp-blog/oracle-java-lice... >Once again, whatever we did 8 years ago I didnt (particularily) place any blame. If it wasnt your testing that was catching them early it must have been someone elses. Presumably they left the ecosystem. >the JDK is completely open. But a shadow of its former self. >but we don't have more bugs than before Im really talking about issues related to very long running jvms. The kind of things that would have killed applications like apache tomcat dead. In fact it looks like they use their own jvm build now, I'll give that a go at the same time..... however it looks they they are still really on 8 as well.
- pron 5y ago
  > They replace adoptOpenJDK https://adoptopenjdk.net/ https://adoptopenjdk.net/ ... Yep, it's the same IBM team, who aren't involved in OpenJDK (and weren't when they were called AdoptOpenJDK). They mostly know OpenJ9. > https://www.policypak.com/resources/pp-blog/oracle-java-lice https://www.policypak.com/resources/pp-blog/oracle-java-lice... Almost everything here is wrong. The prices and licensing terms are very wrong, but, most importantly, what Oracle did was, instead of provide one part-free, part-paid, JDK, we started providing two indentical ones with different licenses: one completely free, and one for support subscribers. > But a shadow of its former self. Actually, it has many more features today than it did back in 8.
DarkmSparks 5y ago
Not sure if you'll catch this message any time soon, but: 1. major source of incompatibility was the removal of the ability to cast ClassLoader to a URLClassLoader, fixes for that were relatively extensive but also simple enough to get running in a few days. 2. Not seen any crash reports in the first 24 hours which is a good sign, any that do come up I will forward as bug reports. 3. Perf wise, about equal, memory usage is much better. 4. Thanks for the impetus to give migrating another go.