4 ms·
If you see crashes -- report them; they're either bugs in the JDK or possibly the result of a library you're using that employs native code or Unsafe in a way t
by pron 5y ago
If you see crashes -- report them; they're either bugs in the JDK or possibly the result of a library you're using that employs native code or Unsafe in a way that depends on a JDK 8 implementation detail. Overall, there has not been any increase in reported crashes since 8.
> but to who and under what title? Oracle, IBM, openjdk?
The most popular Java implementation by far -- the one that serves as the basis for almost all distributions except IBM's -- is called OpenJDK, and is lead by Oracle, with contributions from Red Hat, Intel, Google, Amazon and others. You report the bug to whomever you get your JDK from, and they report it to the OpenJDK project.
> e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?
CORBA works fine, it's just not distributed as part of the JDK anymore. Like most decisions around OpenJDK and the Java spec, it was made by Oracle-employed engineers (like myself), and signed off by representatives of other companies. The reasoning is that it would do more good for more people if the core team behind OpenJDK would spend their efforts on things other than maintaining CORBA, and the reaction from the community has been positive.
- DarkmSparks 5y ago>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 agoYou'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+.