4 ms·
> 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 fol
by 66fm472tjy7 4y ago
> 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.
- twic 4y agoAre you really actually using CORBA? That would be heartwarming if so. Maybe just RMI over IIOP?
- 66fm472tjy7 4y agoIt'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/java/com/eaio/uuid/UUID.java#L55 https://github.com/stephenc/eaio-uuid/blob/master/src/main/j... [1] https://github.com/ulid/spec https://github.com/ulid/spec
- twic 4y agoShame :( 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.