sun.misc.Unsafe has not been removed or blocked, and yes, there's also safe replacements -- VarHandles and the foreign memory API -- for much of its functionality, which will be removed piecemeal.

> I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run.

Huh? How? We've open sourced the entire JDK, making it -- for the first time in Java's 25-year history -- 100% open-source, and we did away with major releases altogether, keeping only the minor ones, and making upgrades cheaper and easier. It's true that some people have not yet internalised what the change means, though. All change is scary, but this one is definitely better for users and for FOSS Java.

In my opinion (obviously a downvoted one but whatever), it fundamentally destabilized the whole ecosystem with a massive deluge of near-breaking changes.

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.

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.

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.

As someone who very much felt the pain of stagnation in Java during the long release-cycles of the Java 5 to 8 era, I'm wildly enthusiastic about the new six-monthly release cycle.

Most of my clients use OpenJDK and don't pay for support of Java per se, so there are plenty of us outside the blast radius enjoying the benefits.

I can't find a reference off hand, but from following along the JDK-Dev mailing list the philosophy is not to remove sun.misc.unsafe until all the features are available in other public APIs. They're well aware of how important it is.

Hopefully someone else can chip in with a better reference or I can find an appropriate cite to back this up.

Edit: Ah, here's an example: https://openjdk.java.net/jeps/396

> It is not a goal to remove, encapsulate, or modify any critical internal APIs of the JDK for which standard replacements do not yet exist. This means that sun.misc.Unsafe will remain available.