5 ms·

>they're either bugs in the JDK here is the documentation I found describing what i would see in anything on post jdk8 that would compile: https://docs.oracle

>they're either bugs in the JDK here is the documentation I found describing what i would see in anything on post jdk8 that would compile: https://docs.oracle.com/en/java/javase/11/troubleshoot/fatal-error-log.html https://docs.oracle.com/en/java/javase/11/troubleshoot/fatal... How to get from that to a (useful) bug report of what broke after 25 hours uptime in the newer jvm, tried most I found, openjdk, oracle, IBM before running out of time. >CORBA works fine Use almost everything removed in https://docs.oracle.com/en/java/javase/11/migrate/index.html https://docs.oracle.com/en/java/javase/11/migrate/index.html Which reminds me that the migration cost estimate came in at 7 figures for no clear benefits. Decision after that was to keep running on what we have working and watch for how ruby/rust/go etc develop. We had actually _just_ started a javaFX project only a few weeks before finding out it was removed. That project was binned and we went over to android apps instead. In fact looking at the schedule, almost all new projects are Android based now - all the old code (that still compiles) works fine there and google have amazing instrumentation for when consumer side stuff breaks.

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
- 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.
vips7L 5y ago
> We had actually _just_ started a javaFX project only a few weeks before finding out it was removed. That project was binned and we went over to android apps instead. You were going to start a _new_ project on an old runtime? There’s no logic here.
- DarkmSparks 5y ago
  javafx was released and pulled in between lts versions. introduced in 9 and removed in 11. https://www.infoworld.com/article/3261066/javafx-will-be-removed-from-the-java-jdk.html https://www.infoworld.com/article/3261066/javafx-will-be-rem... 11 is still the most recent LTS version, 17 doesnt even have a openjdk release yet never migrated to 11 because nothing we have running perfect on 8 ever passed its unit tests on 11. Even the 17 release notes basically seem to imply 17 is not ready for production.
  - vips7L 5y ago
    But you’re making a _new_ project. Just make it on 11 and pull the openjfx jar into the build file.
    - DarkmSparks 5y ago
      It was a project started just before 11 was announced along with javafx's removal. Being removed meant any install on clients machines would be problematic (possibly why it was removed) So the project was reassessed, and everything that was going to use javafx was replaced with webkit/html5/css/js which was expected to be and turned out to be much easier to deploy and far far more portable.

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

vips7L 5y ago

> We had actually _just_ started a javaFX project only a few weeks before finding out it was removed. That project was binned and we went over to android apps instead. You were going to start a _new_ project on an old runtime? There’s no logic here.

DarkmSparks 5y ago
javafx was released and pulled in between lts versions. introduced in 9 and removed in 11. https://www.infoworld.com/article/3261066/javafx-will-be-removed-from-the-java-jdk.html https://www.infoworld.com/article/3261066/javafx-will-be-rem... 11 is still the most recent LTS version, 17 doesnt even have a openjdk release yet never migrated to 11 because nothing we have running perfect on 8 ever passed its unit tests on 11. Even the 17 release notes basically seem to imply 17 is not ready for production.
- vips7L 5y ago
  But you’re making a _new_ project. Just make it on 11 and pull the openjfx jar into the build file.
  - DarkmSparks 5y ago
    It was a project started just before 11 was announced along with javafx's removal. Being removed meant any install on clients machines would be problematic (possibly why it was removed) So the project was reassessed, and everything that was going to use javafx was replaced with webkit/html5/css/js which was expected to be and turned out to be much easier to deploy and far far more portable.