[pron]

> But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users.

The main backward incompatible changes between 8 and 9 were the changing of the version string to remove the "1." prefix, and the removal of a handful of methods hardly anyone had used. In other words, the chances of spec-compliant code that ran on 8 failing on 9 were slim. What happened was that in the long 8 timeframe, many libraries -- for various reasons, some reasonable -- have circumvented the Java spec and hacked into JDK internals, making themselves tightly coupled to 8. When internal classes changed in 9, those non-portable libraries broke, and so did their clients. Now that strong encapsulation is finally turned on (as of JDK 16), this shouldn't happen again.

There were some significant breaking changes to the spec in 11, but those comprised separating modules from the JDK into external dependencies, and didn't require any code change.

[malfist]

I remember there were a lot of libraries that were part of the jdk that got decoupled and no longer included in the move from java8 to java9. I specifically remember this impacting anyone who parsed xml or json. I vaguely remember it being something in the javax.validation package.

My company migrated from 8 to 11 but we had a lot of headaches around those libraries that were pulled out of the jdk.

To be fair, those should not have been coupled to the jdk in the first place, but it did break backwards compatibility which was a cardinal sin for java.

[iainmerrick]

For a lot of people, Java is mainly used to turn XML files into stack traces, so breaking backwards compatibility in XML parsing is a big deal!

Although, if it gives you a stack trace even faster than before, I guess it could be considered a performance improvement...

[vbezhenar]

XML parsing works just fine. It's SOAP and some other classes that were dropped.

I'm not sure if that's a real problem. All it takes is to add few dependencies to pom.xml.

[malfist]

It mattered to us. Our team owned over 50 microservices that all had to have their pom.xml files updated.

But it was worth it. Got us access to the java flight recorder which is an awesome debugging tool.

[mbfg]

things like jaxb were removed, which i'm guessing plays a part in the soap discussion above. Not that it is difficult to fix, but...

[pabl0rg]

Unfortunately, the only explanation I found for my troubles with SOAP and java 11 is found in the comments to this answer in StackOverflow: https://stackoverflow.com/questions/58319199/java-lang-class...

[baud147258]

> the removal of a handful of methods hardly anyone had used

when we moved from java 7/8 to java 11 two years ago, we didn't had any issue with our third-party libraries, but we had a few pieces of code, mostly related to encryption libraries, that failed to compile with the newest JDK