As to the changes, they aren't "near breaking." There have been few breaking spec changes, and they were very small. What breaks is what had always broken code: reliance on internal undocumented classes that change. The reason this happens more now than in the past is not due to spec backward compatibility -- we're as compatible as ever for most intents and purposes -- but because Java was stagnant for a good while, starting with Sun's dying days, and Oracle has been steadily increasing investment in the platform, which means more work done, which means more implementation changes. I think few would say this is a bad thing, but it also means that more code that does what it's warned not to do -- breaks. We're trying to stop this by turning on encapsulation in JDK 16, which would gradually stop libraries from hacking into the JDK and becoming stuck at any specific version.
Re:Talking to Postgres Through Java 16 Unix-Domain Socket Ch...
by pron on Friday February 05, 2021 @07:23PM
(#26042918)
What you're describing is real in some places (Java's ecosystem also includes much/most of Apple, Netflix, Amazon, Google, Twitter, Uber and many others like them), but it is not a result of the new release model. The free support period of JDK 8 ended, like all versions before it, after five years. People who'd want to stay on 8 would have had to pay even if the release model stayed the same.
I get for startups or people running immediate-to-production deployments that it is doable.
But Java's ecosystem is boring, staid enterprise, and those people are still running critical systems on Windows XP or worse. IF they are dragging their feet on THAT...
The churn basically stuns these people into 1) staying on Java8 for a LONG time, or 2) look at rewriting the system in something else, or 3) scaring them into paying money.
I have been doing mostly groovy for the last 10 years so not a single feature in the Java besides invokedynamic (which was really a JVM feature not a Java feature) has impacted me in a good way. Meanwhile... that churn.
As a Cassandra user I have seen the "what the hell do we target" conversation play out for 4.0 planning on the dev list, besides the sun.misc stuff. Maybe since (gah AMAZON's Corretto, seriously we have to rely on AMAZON being a good steward of OSS) then the coordination of patching and providing builds has stabilized outside of Oracle offered downloads, but it was a bit unsettling for a while.
So while I get that a lot of people see that as "being nimble" and "moving fast", those are precisely NOT what Java has historically been, for better or worse.