Hacker News new | ask | show | jobs
by ffsm8 247 days ago
Uh, wasn't the only breaking change a rename/changed path in some standard lib path?
2 comments

Deprecations, which also affects libraries, i.e. the dusty one you were chugging along on top of might need to be replaced or adopted because the original maintainer gave up years ago.
Introduction of modules, closing down of APIs that no one should be using, since Java 9 deprecated methods actually get removed a few versions later.

Also breaking changes do happen, see list of removed methods

https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...

On top of that, there was the removal of built-in J2EE; you needed to add external copies of the J2EE pieces, and some of them (like CORBA) weren't available as separate packages. And later versions of these external J2EE packages changed the namespace of all their classes, which is especially painful in Java due to its common use of dynamic loading of classes by name and lazy linking (and lazy linking errors do not inherit from Exception, which allows them to escape from catch-all "catch (Exception e)" clauses). The rest of the ecosystem is starting to depend on these new versions, so staying with old versions of these J2EE packages is not an option.
The fact that Sun never removed any deprecated methods even after they were proven dangerous was a sticking point that generated friction between coworkers over new code using deprecated functionality.