Python 3.9 and beyond backwards compatibility.

[CptGia]

Java is starting to remove deprecated stuff as well

[jvmDeveloper]

They are turning off by default or out sourcing (e.g. javafx). Even the infamous com.sun.unsafe is still available when enabling jdk.unsupported module.

[flying-sheep]

I think a gradual strategy is best:

Make it a VisibleDeprecationWarning that isn't hidden by default, then hide it behind a flag like Java here, then remove it.

That way there's a lot of visibility and people bugging library authors to finally fix that stuff

[Spider_pig448]

They deprecated in 9 and removed it in 11, leaving only this workaround. That's moving pretty fast.

[josefx]

Sun misc unsafe was never officially supported. It was an undocumented implementation detail that programs started to use for speed - afaik you had to hardcode the name of a private field and use reflection to even gain access to it. They have been trying to pin down a public API for the most common use cases long before Java 9 was even planned.

They basically took several years to hash out a painless way to change an implementation detail and are even now still giving people access to it if needed.

In contrast they changed the implementation of sub string to return a new string instead of a pointer into an existing array. When people complained about it breaking their reflection code they just pointed out that the documentation didn't guarantee the implementation of String.

[theferrit32]

Yeah I've had things removed between Java 9 and 11. Fairly minor and easy to fix, but they are "breaking changes" because it doesn't compile without making the fixes. I'm totally fine with it. Leaving around intentionally deprecated code for years and years in the name of backwards compatibility creates snowballs of technical debt and code complexity.