Almost. The Java module system (introduced in Java 9 and enforced in Java 11) still plagues companies and/or slow-to-update libraries. Particularly companies that have written a lot of their own in-house libraries and such.

Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* packages, etc.). So companies are wedged in because they made the poor decision to rely on private packages. And now, Java 11+ enforces this by default.

There are open source Java libraries today that don't run unless you "add-exports" to basically everything. google-java-format comes to mind, because it's using an internal java code parser from the JDK, for example.

In the latest LTS those all can still be enabled, so while it is a serious problem when they are finally removed, for now it's not really a good reason to block an upgrade.

I think that's fair. Yes, there is an escape hatch currently available. But what is hard is knowing if your application is relying on any internal/private behavior that it shouldn't. Since the dependency hierarchy of most Java projects is very deep, it's hard to know if any dependencies of A -> B -> C -> D are going to call into restricted areas. You might not even know you have a problem until runtime, because you've --add-exports everything and now you have a stacktrace to try and deal with in production.

But yes, maybe not a good reason to completely block an upgrade. It's just postponing the pain, though.

> Everything should be a drop-in replacement

It isn't at all, in my opinion. Consider the introduction of the module system, for example.

Some libraries moved out of the core language.

Isn't 202 the last version?

Except 9, 11, 14 and 16 where breaking backwards incompatible changes were introduced? And then the talk of changes in libraries, remapping imports from JEE to Jakarta... that's a long, long way in Java.

> Everything should be a drop-in replacement

This is not true for many applications. Due to the removal of many APIs from the JDK with Java 9, I needed the following dependency artifactIds to be able to move a JEE application with SOAP web services to Java 11: jaxb-api, jaxb-core, jaxb-runtime, istack-commons-runtime, jboss-jaxws-api_2.2_spec, glassfish-corba-omgapi, jboss-annotations-api_1.2_spec, activation, jboss-saaj-api_1.3_spec, saaj-impl, stax-ex, jsr181-api, txw2.

Many of these spec API/implementations are provided by different artifacts that are incompatible with each other. Some I only discovered when something failed at runtime as they perform implementation lookups and you don't get compile errors.

Additionally, many of the Maven plugins we used no longer worked and our application server failed to start.

Are you really actually using CORBA? That would be heartwarming if so. Maybe just RMI over IIOP?

It's far less exciting I'm afraid: we use [0] to generate our DB IDs and it implements org.omg.CORBA.portable.IDLEntity.

We could fork it and remove the interface or switch to ULID[1] instead.

[0] https://github.com/stephenc/eaio-uuid/blob/master/src/main/j...

[1] https://github.com/ulid/spec

Shame :(

Given that interface is trivial, you could also just define it in your codebase. I've done that a few times for shimming small bits of log4j and Spring that some library uses, when i would rather not have those as a dependency.