> With flags to recover the previous behavior

I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10.

> the changes of which only broke code using non-public API surface

The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.

They were non-public, at least all the ones that I recall being broken (from memory, but let me know if I’ve missed something important here: URLClassLoader, Base 64 classes (made public under a different name), unsafe: name implies the contract to some extent, but also still available under a flag. Then there’s the whole slew of things like DNS resolvers that override internal classes, but again- weren’t supposed to be for “public” consumption.

Ultimately, the break seems to have been intentional, but did receive appropriate consideration. Mark’s comments about moving forward do address these points.

Modularization "broke" a few public APIs since they had to remove an interface declared in swing from some classes outside of the package. I am not sure if there is even one known case of anyone being affected by that change.