7 ms·

Those crashes were just on our unit tests, creating linking and destroying large volumes of objects, throwing them in a thread for some basic compute then writi

Those crashes were just on our unit tests, creating linking and destroying large volumes of objects, throwing them in a thread for some basic compute then writing results to disk. I agree its really about the gc, but the new ones just never seemed to beat the setup we have on 8, and there is only so much time that can be devoted to making things that work, work on "new shiney". java after 8 is just mayhem, before it was easy, oracle for some things, ibm for others. now there are new long term releases faster than we can test them, they fail at least one of the unit tests that all pass on 8, and openjdk is missing half the really nice stuff that was once free. >submit a bug report but to who and under what title? Oracle, IBM, openjdk? e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?

crummy 5y ago
> now there are new long term releases faster than we can test them Aren't they every 2-3 years?
- DarkmSparks 5y ago
  now yes. fixing what isnt broken isnt high on the list of things to do.
  - rualca 5y ago
    > fixing what isnt broken isnt high on the list of things to do. It's hardly reasonable to try to pin the blame of not wanting to maintain software as a stability issue with a newer LTS release of the JDK. It's perfectly fine if you make the call to stick with JDK8 forever, but that's a personal call.
- quantified 5y ago
  They’re pretty well spaced out.
  - DarkmSparks 5y ago
    used to be. java 6 (previously widely deployed jvm) was 2006 java 8 (current widely deployed jvm) was 2014 now, 7 years later, we are on java 17 and the most significant thing to change is to break most everything that worked in 2014, and promotional material dare not mention java 8... In fact "widely deployed" doesnt cut it for java 6, pretty much every pc, windows linux and mac had a solid java 6 deployment. java 17 has a lot to live up to.
sandGorgon 5y ago
this is super interesting. Honestly, I do think that your testcase is worth replicating. I dont think anyone is advocating you tradeoff stability for shiny features, but i think everyone is existing in a state of disbelief that Java 17 would break on your usecase. But if what you're saying is true... it super duper worth it for everyone to submit that test suite. Java 17 is also LTS ...so that effort would be worth it in the long term.
- DarkmSparks 5y ago
  I really think they are "trading off stability for shiny features" Oracle wanted money from google for using java to create google search and creating Android. Didnt get any, and now they are trying to attract devs who are starting similar ground breaking ideas on go and rust with a similar disregard for robust failure states and long term code viability which is always what separated java from its competitors. Why else depreciate all the features that made it perfect for huge teams building systems that never broke and adding "things rust, go and v8 did"? as for the test suite, not touched java 17, looking at the "whats new" the main thing I can say for sure is "new" is all the security manager stuff that wraps code made by 3rd parties is going to be marked with depreciated, but no clear upgrade path.
  - sandGorgon 5y ago
    look - the tradeoff here is large vs large. I detect a certain disdain for Android - however there is probably a larger dev pool right now who want that (versus you). I dont disrespect your usecase, but any company would have to service its largest market first. And if the largest markets are all Android, Spring Boot, Kafka, Spark, etc... then that's where they will go. I have been in your situation, but ultimately this is a Python 2 vs Python 3 situation. If you want to stay on Python 2..then you better be able to maintain it yourself. Its just a larger pool of users on the other side. And this is the common developer on the street wanting to use Kotlin, Clojure, etc. This is the market, so here we are.
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.
  - 5y ago

crummy 5y ago

> now there are new long term releases faster than we can test them Aren't they every 2-3 years?

DarkmSparks 5y ago
now yes. fixing what isnt broken isnt high on the list of things to do.
- rualca 5y ago
  > fixing what isnt broken isnt high on the list of things to do. It's hardly reasonable to try to pin the blame of not wanting to maintain software as a stability issue with a newer LTS release of the JDK. It's perfectly fine if you make the call to stick with JDK8 forever, but that's a personal call.
quantified 5y ago
They’re pretty well spaced out.
- DarkmSparks 5y ago
  used to be. java 6 (previously widely deployed jvm) was 2006 java 8 (current widely deployed jvm) was 2014 now, 7 years later, we are on java 17 and the most significant thing to change is to break most everything that worked in 2014, and promotional material dare not mention java 8... In fact "widely deployed" doesnt cut it for java 6, pretty much every pc, windows linux and mac had a solid java 6 deployment. java 17 has a lot to live up to.

sandGorgon 5y ago

this is super interesting. Honestly, I do think that your testcase is worth replicating. I dont think anyone is advocating you tradeoff stability for shiny features, but i think everyone is existing in a state of disbelief that Java 17 would break on your usecase. But if what you're saying is true... it super duper worth it for everyone to submit that test suite. Java 17 is also LTS ...so that effort would be worth it in the long term.

DarkmSparks 5y ago
I really think they are "trading off stability for shiny features" Oracle wanted money from google for using java to create google search and creating Android. Didnt get any, and now they are trying to attract devs who are starting similar ground breaking ideas on go and rust with a similar disregard for robust failure states and long term code viability which is always what separated java from its competitors. Why else depreciate all the features that made it perfect for huge teams building systems that never broke and adding "things rust, go and v8 did"? as for the test suite, not touched java 17, looking at the "whats new" the main thing I can say for sure is "new" is all the security manager stuff that wraps code made by 3rd parties is going to be marked with depreciated, but no clear upgrade path.
- sandGorgon 5y ago
  look - the tradeoff here is large vs large. I detect a certain disdain for Android - however there is probably a larger dev pool right now who want that (versus you). I dont disrespect your usecase, but any company would have to service its largest market first. And if the largest markets are all Android, Spring Boot, Kafka, Spark, etc... then that's where they will go. I have been in your situation, but ultimately this is a Python 2 vs Python 3 situation. If you want to stay on Python 2..then you better be able to maintain it yourself. Its just a larger pool of users on the other side. And this is the common developer on the street wanting to use Kotlin, Clojure, etc. This is the market, so here we are.

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.
- 5y ago