3 ms·

> How to get from that to a (useful) bug report Start by submitting the hs_err file. > almost everything removed It was removed from the JDK and made availab

by pron 5y ago

> How to get from that to a (useful) bug report Start by submitting the hs_err file. > almost everything removed It was removed from the JDK and made available as a separate module (contributed to Eclipse): https://github.com/eclipse-ee4j/orb https://github.com/eclipse-ee4j/orb > Which reminds me that the migration cost estimate came in at 7 figures for no clear benefits. Most companies report a ~10% reduction in hardware costs, and more than make up for any migration costs (which are quite low these days) in under a year. See this experience from LinkedIn: https://channel9.msdn.com/Events/Java/JDConf-2020/Java-11-Journey-at-LinkedIn https://channel9.msdn.com/Events/Java/JDConf-2020/Java-11-Jo... In other words, the benefits are usually significant savings, even if you don't use any new features.

native_samples 5y ago
You're assuming a heavily replicated horizontally scaled service. A lot of Java servers run on one or two servers. Hardware costs are immaterial compared to people/opportunity costs. Fact is, Java now has a reputation for pointless churn that it once didn't have. For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it and would reduce the churn but instead it's now needing new gradle/maven plugins and stuff. Ditto for all the other stuff that's being kicked out. Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. Some syntax sugar and better GCs. If you're CPU constrained better perf but a lot of apps aren't. They're feature constrained.
- pron 5y ago
  > Hardware costs are immaterial compared to people/opportunity costs. First, the fact is that companies do care a lot about those costs, and why not have both? The early problems with the 8->9+ migrations were inevitable, as libraries became coupled to internals. There were two options: stop improving the platform, or get some short-term pain in exchange for a couple more decades at the top. > Fact is, Java now has a reputation for pointless churn that it once didn't have. It does have more churn than it once did, because that's what more people want. It's still significantly less churn than any other popular language/platform out there, with the exception of C. > For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it I understand why it might appear to be easy to start bundling JavaFX with OpenJDK, but it's not. There is no one in the world more personally invested in the success of the platform than the people maintaining it, and we need to constantly choose where to put our resources. With an ecosystem so big, no matter what we do there are bound to be quite a few people who are disappointed with the budgeting, but the amazing resurgence we're seeing speaks for itself. > Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+.
  - native_samples 5y ago
    JavaFX is still maintained by Oracle so I don't see how budgets are related, the JDK ships lots of modules that aren't a part of the Java SE spec, and adding it in is a simple matter of jlinking it. It would be very easy to start bundling it again. I'm sure there's some explanation for separating it that makes sense if you're very close to things, but whatever the underlying rationale: that one move broke every JavaFX app simultaneously. JavaFX is the most modern GUI library, the one Sun/Oracle promoted for years as the replacement for Swing and yet new Java releases cannot run any old releases of any of those apps. That's what people mean when they say Java lacks backwards compatibility: their apps stop running.
    - pron 5y ago
      > JavaFX is still maintained by Oracle Yes and no. Yes, we still have some Oracle engineers contributing, but development is co-led with Gluon, and not at the same standard of contribution as other Oracle-led OpenJDK efforts. Second, the problem isn't the actual building of the package, but the lack of desire to coordinate releases. Same goes for the EE modules -- which orders of magnitude more people use than JavaFX. > that one move broke every JavaFX app simultaneously > Java lacks backwards compatibility: their apps stop running. Yes, but given that Java's backward compatibility is significantly stronger than pretty much anyone else's (except maybe C), it's important to understand that its former, even stronger form, was not so much by design, but by unfortunate necessity -- investment in the platform was low, and so the rate of change. There is simply no way to let the complexity of the JDK grow monotonically, so things have to be removed or separated. If, say, 1 in every 100 projects has to make a code change (not just include external packages) only once every few years -- we're very happy with that. We put a very high premium on backward compatibility, certainly compared to other platforms, but it's not absolute, as that would entail stopping the platform's evolution. Especially now with the disappearance of the JRE, the addition of jlink and the move toward embedded runtimes, aiming for 100% compatibility for 100% of users is not even necessary.
  - DarkmSparks 5y ago
    >You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+. Ooopf. Only way I see that being possible is if 11+ can be adopted by the ecosystem without significant rewrites of code and build scripts. Has that situation really improved enough since the nightmare 8 to 11 migration requirements locked in most of the ecosystem on 8 for production builds and where can we read about it?
DarkmSparks 5y ago
>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.

by pron 5y ago

native_samples 5y ago

You're assuming a heavily replicated horizontally scaled service. A lot of Java servers run on one or two servers. Hardware costs are immaterial compared to people/opportunity costs. Fact is, Java now has a reputation for pointless churn that it once didn't have. For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it and would reduce the churn but instead it's now needing new gradle/maven plugins and stuff. Ditto for all the other stuff that's being kicked out. Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. Some syntax sugar and better GCs. If you're CPU constrained better perf but a lot of apps aren't. They're feature constrained.

pron 5y ago
> Hardware costs are immaterial compared to people/opportunity costs. First, the fact is that companies do care a lot about those costs, and why not have both? The early problems with the 8->9+ migrations were inevitable, as libraries became coupled to internals. There were two options: stop improving the platform, or get some short-term pain in exchange for a couple more decades at the top. > Fact is, Java now has a reputation for pointless churn that it once didn't have. It does have more churn than it once did, because that's what more people want. It's still significantly less churn than any other popular language/platform out there, with the exception of C. > For example kicking JavaFX out of the default JDK builds makes no sense outside the world of Oracle corp politics. It would be easy to keep bundling it I understand why it might appear to be easy to start bundling JavaFX with OpenJDK, but it's not. There is no one in the world more personally invested in the success of the platform than the people maintaining it, and we need to constantly choose where to put our resources. With an ecosystem so big, no matter what we do there are bound to be quite a few people who are disappointed with the budgeting, but the amazing resurgence we're seeing speaks for itself. > Also people won't use incubator modules so realistically new Java's have very few new features that can justify the painful upgrade process. You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+.
- native_samples 5y ago
  JavaFX is still maintained by Oracle so I don't see how budgets are related, the JDK ships lots of modules that aren't a part of the Java SE spec, and adding it in is a simple matter of jlinking it. It would be very easy to start bundling it again. I'm sure there's some explanation for separating it that makes sense if you're very close to things, but whatever the underlying rationale: that one move broke every JavaFX app simultaneously. JavaFX is the most modern GUI library, the one Sun/Oracle promoted for years as the replacement for Swing and yet new Java releases cannot run any old releases of any of those apps. That's what people mean when they say Java lacks backwards compatibility: their apps stop running.
  - pron 5y ago
    > JavaFX is still maintained by Oracle Yes and no. Yes, we still have some Oracle engineers contributing, but development is co-led with Gluon, and not at the same standard of contribution as other Oracle-led OpenJDK efforts. Second, the problem isn't the actual building of the package, but the lack of desire to coordinate releases. Same goes for the EE modules -- which orders of magnitude more people use than JavaFX. > that one move broke every JavaFX app simultaneously > Java lacks backwards compatibility: their apps stop running. Yes, but given that Java's backward compatibility is significantly stronger than pretty much anyone else's (except maybe C), it's important to understand that its former, even stronger form, was not so much by design, but by unfortunate necessity -- investment in the platform was low, and so the rate of change. There is simply no way to let the complexity of the JDK grow monotonically, so things have to be removed or separated. If, say, 1 in every 100 projects has to make a code change (not just include external packages) only once every few years -- we're very happy with that. We put a very high premium on backward compatibility, certainly compared to other platforms, but it's not absolute, as that would entail stopping the platform's evolution. Especially now with the disappearance of the JRE, the addition of jlink and the move toward embedded runtimes, aiming for 100% compatibility for 100% of users is not even necessary.
- DarkmSparks 5y ago
  >You're entitled to that opinion, but in a few short months the majority of the ecosystem is expected to be on 11+. Ooopf. Only way I see that being possible is if 11+ can be adopted by the ecosystem without significant rewrites of code and build scripts. Has that situation really improved enough since the nightmare 8 to 11 migration requirements locked in most of the ecosystem on 8 for production builds and where can we read about it?

DarkmSparks 5y ago

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