First, not to sound ungrateful, I appreciate everything over at OpenJDK does and thank them for being excellent stewards of the ecosystem. Their fair and balanced approach, while putting backwards compatibility at the forefront, is something very rare these days.

> Legacy bugs have been fixed so it is exceptionally rare to need to break encapsulation to work around them.

I do think their line of thinking is quite optimistic. Take this famous bug: https://bugs.openjdk.org/browse/JDK-8207840 which was set to Resolved, Won't Fix and instead the recommend a newer API. Here's the thing, a lot of third party code still uses the older API. A major use case is attempting to call the SalesForce API using HTTPUrlConnection or a library that wraps this class... Good luck. Despite SalesForce being extraordinarily common, you simply can't call it using the JDK's standard classes as the SF API required HTTP PATCH.

The only workaround we can find, save building/patching an entire JDK, is at Runtime, to do some dirty things to the JDK with the Reflection and/or Unsafe APIs. We'd love to migrate every app to the latest JDK where HTTP PATCH might be supported, but RuntimePatching allows us to not have to cross that bridge.

As a matter of fact, we have a JVM Agent that intercepts class loads and can patch 3rd Party Libraries on the fly. This allows us to immediately deploy fixes to prod when things like Spring4Shell appear.