A tidal wave is rippling by way of the Java ecosystem. It’s the renaming of javax to jakarta bundle names. Now, whereas we’ve all been whining and complaining and shaking our heads due the conflict between company authorized and engineering pursuits, finally it’s time to maneuver on and study what this implies particularly, for jOOQ.
jOOQ has 3 Java EE dependencies in complete:
- JAXB – That is fairly the ever present dependency in jOOQ, and it’s the one we’ll talk about largely on this weblog put up. It’s utilized by the jOOQ runtime and code era modules, and it at present isn’t non-compulsory (a minimum of the API must be current).
- JPA – That is an non-compulsory dependency in jOOQ. The jOOQ runtime can map to JPA entities to some extent, and the code generator can generate entity annotations to some extent.
- Bean validation – This isn’t a proper dependency. The code generator can generate bean validation annotations, and that’s it.
All of those 3 dependencies have been migrated to Jakarta EE in jOOQ 3.16 with Situation #9641. The change was inevitable in some unspecified time in the future, however on condition that Spring Boot 3.0 will migrate as properly, and quickly eliminated jOOQ from their growth builds (see spring-boot#28821), I assumed we’d as properly migrate now.
What does the migration imply for jOOQ, particularly?
JAXB
JAXB is the largest Java EE dependency, and likewise the one we are able to’t eliminate simply. No less than not of the API. There are 3 widespread XML codecs which might be at present marshalled and unmarshalled utilizing JAXB:
Particularly, the code era configuration’s JAXB annotations are very helpful, as customers can merge XML information with programmatic code era configuration simply. Additionally, the favored gradle-jooq-plugin third social gathering contribution by Etienne Studer works by introspecting the annotations.
As a result of mess created by the JDK 11’s removing of the JAXB API and implementation, we’ve already applied our personal “MiniJAXB” implementation that satisfies our restricted JAXB wants. This enables for working with jOOQ even when there’s no JAXB implementation on the classpath. However the API continues to be necessary, and as mentioned right here, it appears we are able to’t eliminate it simply.
JPA
Our DefaultRecordMapper can map to JPA entities to some restricted extent. This enables for simpler migrations from JPA to jOOQ in addition to use annotation primarily based mapping for individuals who like that, with out re-inventing our personal customized annotations.
On the similar time, the code generator may be configured to generate JPA annotations on generated POJO lessons, largely for a similar DefaultRecordMapper utilization functions, far more than to make use of the generated code as precise entities.
Each of those options have at all times been controversial and this entire new Java EE vs Jakarta EE trouble could also be a tipping level in favour of eradicating them finally. The choice has not been made but, however this space is definitely not the place jOOQ generates most worth.
Bean validation
We don’t implement bean validation, but it surely has at all times been a low hanging fruit to generate a number of bean validation annotations on generated POJO lessons in jOOQ, simply to counterpoint your POJOs with some well-known meta information, corresponding to e.g. @Dimension for a string. Since we don’t have a tough dependency on this Jakarta EE undertaking (solely your generated code does, and provided that you decide in to this), this concern isn’t actually affected a lot by the migration to Jakarta EE
Backwards suitable or not?
So, on condition that we needed to take motion in jOOQ 3.16 or on the newest in jOOQ 3.17 (given Spring Boot’s comprehensible stance), the query was:
- Ought to we provide help for each Java EE and Jakarta EE APIs for some time?
- Ought to we transfer on and neglect about Java EE?
- Ought to we drop help for the integrations?
Clearly, dropping help wasn’t an possibility for JAXB (although it was for JPA and Bean Validation). Supporting each in parallel might work, with two sub-options:
- Ship a single artifact with each dependencies
- Ship a number of artifacts, one for every dependency
The previous is simply asking for bother. Not for jOOQ. It could be easy for jOOQ to help each APIs, however having each APIs on all jOOQ consumer classpaths is simply horrible and would trigger so many points in consumer tasks.
Transport a number of artifacts can be clear and permit for customers to resolve on their very own what to do. That is what many different tasks did, e.g. Hibernate. However those that did this had a powerful dependency on Jakarta EE tasks, e.g. Hibernate on JPA. It is sensible for Hibernate to separate into two distributions. Not a lot for jOOQ, which makes solely marginal use of those APIs (even of JAXB).
Apart from, jOOQ already has a ton of distributions, which you’ll be able to see on the downloads web page: https://www.jooq.org/obtain/variations.
We have now:
- The jOOQ Open Supply Version
- The jOOQ Trial Version for Java 17
- The jOOQ Trial Version for Java 11
- The jOOQ Trial Version for Java 8
- The jOOQ Professional Version for Java 17
- The jOOQ Professional Version for Java 11
- The jOOQ Professional Version for Java 8
(Observe there have been good causes to not use multi-release jars, in case you have been questioning.)
Now think about the mess if all of those editions wanted one other dimension for the Jakarta EE dependency. That’s not sensible.
So, we bit the bullet and moved on. Ranging from jOOQ 3.16, Java EE has gone and Jakarta EE is our dependency, the place wanted.
The longer term
What all this mess has taught us as soon as extra is that dependencies are a ache. They’re a good larger ache for a library like jOOQ (due to the ache it causes in consumer tasks). We have now an (nearly) zero dependency coverage, which we can’t observe ourselves completely, together with as a result of the JDK determined to ditch JAXB once more in Java 11, after including it in Java 6 (I feel?). JAXB didn’t appear to be a dependency when jOOQ began out, but it surely successfully was.
So, the way forward for jOOQ will finally eliminate these dependencies the place attainable, or transfer them into non-compulsory plugin modules.
