4 ms·

>Start by submitting the hs_err file. Having just read the release notes: https://jdk.java.net/17/release-notes https://jdk.java.net/17/release-notes links h

>Start by submitting the hs_err file. Having just read the release notes: https://jdk.java.net/17/release-notes https://jdk.java.net/17/release-notes links https://bugs.openjdk.java.net/browse/JDK-8263710 https://bugs.openjdk.java.net/browse/JDK-8263710 Similar enough code block in that to what I just described to see there is now/still a known issue in java 17 to kill services after a prolonged period of time. There's no shortage of those hs_err files, deleted a few thousand a while ago when I found out they were the reason a staging server had run out of disk space.

pron 5y ago
> Similar enough code block in that to what I just described to see there is now/still a known issue in java 17 to kill services after a prolonged period of time. That's a crash going back to 8, which 17 is actually reported to reduce (i.e. 17 crashes less than 8 under those circumstances). But, as you can see, when such crashes are reported, they are investigated in depth.
- DarkmSparks 5y ago
  Its one example of issues that never should have made it into a release in the first place of any software that cared about stability. That even attempting to fix got deferred to jre18. From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature", 10% hardware savings wouldnt cover a fraction of the support costs there even for those spending significant amounts on hardware. OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have.
  - pron 5y ago
    > Its one example of issues that never should have made it into a release in the first place of any software that cared about stability. You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8. > From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature", Once again, that bug -- for that particular class of processors -- is in 8 as well, and the crash occurs less often in 17 than it does in 8. > OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have. Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame.
    - DarkmSparks 5y ago
      >You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8. Obviously, since it was me that just spent the last few days explaining stability and migration options went downhill so fast after 8 we got stuck there for production systems. Do you? >Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame. But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing? Or really just not considered an important feature for java to worry about? Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code? All that really just sounds like intentional sabotage to me.
      - pron 5y ago
        > went downhill so fast after 8 This isn't after 8. The bug is there in 8. And your statement that things went "downhill" after 8 is just factually incorrect, which you can confirm based on publicly available data. > But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing? Given that the bug has been in the JDK for at least eight years, and it wasn't detected in production in all those years until now, why is it surprising that it wasn't detected in testing? It occurs only on specific architectures and specific conditions. > Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code? You're implying that SecurityManager is used for security, while it hasn't been a security feature in many years (including in JDK 8). It was a security feature for applets, but virtually all features added in JDK 8 and beyond ignore SM, and Java's security features have not focused on SecurityManager, it is not part of the platform's core security, and Java's secure coding guidelines do not recommend using it. We're removing SecurityManager on the advice of security experts, in an effort to improve security. SM does not only not improve security, but might well harm it. We focus on stability today much more than we did in the 8 timeframe. We have more tests these days that we run more often (thank's to a better CI system), and we merge new features after much more scrutiny and testing than we did in the 8 timeframe. I don't know if you remember, but 8 was largely unusable until the first update. This no longer happens today. New versions are stable on day 1. I'm sorry you've had a bad experience, and in an ecosystem so large running on so many kinds of machines, it might well happen to some, and, understandably, it paints your views. But looking at the ecosystem overall, there is simply no downward trend in stability, and while we haven't yet crunched all the data, we can tentatively say there has been an upward trend.

pron 5y ago

> Similar enough code block in that to what I just described to see there is now/still a known issue in java 17 to kill services after a prolonged period of time. That's a crash going back to 8, which 17 is actually reported to reduce (i.e. 17 crashes less than 8 under those circumstances). But, as you can see, when such crashes are reported, they are investigated in depth.

DarkmSparks 5y ago
Its one example of issues that never should have made it into a release in the first place of any software that cared about stability. That even attempting to fix got deferred to jre18. From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature", 10% hardware savings wouldnt cover a fraction of the support costs there even for those spending significant amounts on hardware. OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have.
- pron 5y ago
  > Its one example of issues that never should have made it into a release in the first place of any software that cared about stability. You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8. > From where I, and Im sure most of "the ecosystem" sits "the jvm eventually explodes if you indefinitely add things to and clear an arraylist" is more than reason enough to not update to any jvm with that "feature", Once again, that bug -- for that particular class of processors -- is in 8 as well, and the crash occurs less often in 17 than it does in 8. > OTOH, it is quite nice that new adopters will by design never be able to achieve the same stability those of us who have been around the block a few times have. Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame.
  - DarkmSparks 5y ago
    >You realise it's been there for many years before being discovered by one of the millions of Java developers out there, yeah? It goes at least as far back as JDK 8. Obviously, since it was me that just spent the last few days explaining stability and migration options went downhill so fast after 8 we got stuck there for production systems. Do you? >Those of us who have been around the block a few times have learned to trust data; if there's any trend in the JDK's stability, it's upward. Our process is so much more careful and the testing more exhaustive than it's been in the 8 time-frame. But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing? Or really just not considered an important feature for java to worry about? Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code? All that really just sounds like intentional sabotage to me.
    - pron 5y ago
      > went downhill so fast after 8 This isn't after 8. The bug is there in 8. And your statement that things went "downhill" after 8 is just factually incorrect, which you can confirm based on publicly available data. > But adding and removing objects to/from an arraylist was somehow missed from that exhaustive testing? Given that the bug has been in the JDK for at least eight years, and it wasn't detected in production in all those years until now, why is it surprising that it wasn't detected in testing? It occurs only on specific architectures and specific conditions. > Better to spend the dev time deleting security manager, because no one in the ecosystem wants or needs to manage application security from java code? You're implying that SecurityManager is used for security, while it hasn't been a security feature in many years (including in JDK 8). It was a security feature for applets, but virtually all features added in JDK 8 and beyond ignore SM, and Java's security features have not focused on SecurityManager, it is not part of the platform's core security, and Java's secure coding guidelines do not recommend using it. We're removing SecurityManager on the advice of security experts, in an effort to improve security. SM does not only not improve security, but might well harm it. We focus on stability today much more than we did in the 8 timeframe. We have more tests these days that we run more often (thank's to a better CI system), and we merge new features after much more scrutiny and testing than we did in the 8 timeframe. I don't know if you remember, but 8 was largely unusable until the first update. This no longer happens today. New versions are stable on day 1. I'm sorry you've had a bad experience, and in an ecosystem so large running on so many kinds of machines, it might well happen to some, and, understandably, it paints your views. But looking at the ecosystem overall, there is simply no downward trend in stability, and while we haven't yet crunched all the data, we can tentatively say there has been an upward trend.