A tidal wave is rippling by means 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, ultimately it’s time to maneuver on and be taught 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 principally on this weblog put up. It’s utilized by the jOOQ runtime and code era modules, and it at present isn’t non-obligatory (at the very least the API must be current).
- JPA – That is an non-obligatory 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 Concern #9641. The change was inevitable in some unspecified time in the future, however provided that Spring Boot 3.0 will migrate as nicely, and quickly eliminated jOOQ from their improvement builds (see spring-boot#28821), I assumed we’d as nicely migrate now.
What does the migration imply for jOOQ, particularly?
JAXB
JAXB is the most important Java EE dependency, and likewise the one we are able to’t eliminate simply. A minimum of not of the API. There are 3 common 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 celebration contribution by Etienne Studer works by introspecting the annotations.
As a result of mess created by the JDK 11’s elimination of the JAXB API and implementation, we’ve already carried out our personal “MiniJAXB” implementation that satisfies our restricted JAXB wants. This permits for working with jOOQ even when there’s no JAXB implementation on the classpath. However the API remains to be obligatory, 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 permits for simpler migrations from JPA to jOOQ in addition to use annotation based mostly mapping for individuals who like that, with out re-inventing our personal customized annotations.
On the similar time, the code generator could be configured to generate JPA annotations on generated POJO courses, principally 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 complete new Java EE vs Jakarta EE problem could also be a tipping level in favour of eradicating them ultimately. 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, however it has at all times been a low hanging fruit to generate a couple of bean validation annotations on generated POJO courses in jOOQ, simply to complement your POJOs with some well-known meta information, reminiscent of e.g. @Dimension for a string. Since we don’t have a tough dependency on this Jakarta EE mission (solely your generated code does, and provided that you decide in to this), this situation isn’t actually affected a lot by the migration to Jakarta EE
Backwards suitable or not?
So, provided 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 assist for each Java EE and Jakarta EE APIs for some time?
- Ought to we transfer on and overlook about Java EE?
- Ought to we drop assist for the integrations?
Clearly, dropping assist wasn’t an possibility for JAXB (although it was for JPA and Bean Validation). Supporting each in parallel may 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 will be easy for jOOQ to assist each APIs, however having each APIs on all jOOQ consumer classpaths is simply horrible and would trigger so many points in shopper tasks.
Transport a number of artifacts could be clear and permit for customers to determine on their very own what to do. That is what many different tasks did, e.g. Hibernate. However those that did this had a robust dependency on Jakarta EE tasks, e.g. Hibernate on JPA. It is smart 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 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
(Be aware 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 long run
What all this mess has taught us as soon as extra is that dependencies are a ache. They’re a fair greater 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 comply with ourselves totally, 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, however it successfully was.
So, the way forward for jOOQ will ultimately eliminate these dependencies the place potential, or transfer them into non-obligatory plugin modules.
