A tidal wave is rippling by the Java ecosystem. It’s the renaming of javax to jakarta package deal 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 whole:
- JAXB – That is fairly the ever-present dependency in jOOQ, and it’s the one we’ll focus on principally on this weblog put up. It’s utilized by the jOOQ runtime and code era modules, and it presently 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 had been migrated to Jakarta EE in jOOQ 3.16 with Challenge #9641. The change was inevitable sooner or later, however on condition that Spring Boot 3.0 will migrate as effectively, and quickly eliminated jOOQ from their improvement builds (see spring-boot#28821), I assumed we would as effectively migrate now.
What does the migration imply for jOOQ, particularly?
JAXB
JAXB is the largest Java EE dependency, and likewise the one we will’t do away with simply. No less than not of the API. There are 3 widespread XML codecs which can be presently 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 removing of the JAXB API and implementation, we’ve already carried out 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 obligatory, and as mentioned right here, it appears we will’t do away with 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 identical time, the code generator might be configured to generate JPA annotations on generated POJO courses, principally for a similar DefaultRecordMapper utilization functions, rather more than to make use of the generated code as precise entities.
Each of those options have all the time 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, however it has all the time 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 knowledge, resembling e.g. @Measurement 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 choose in to this), this challenge 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 assist 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 assist for the integrations?
Clearly, dropping assist wasn’t an choice 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 could 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 initiatives.
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 initiatives did, e.g. Hibernate. However those that did this had a powerful dependency on Jakarta EE initiatives, 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’ve:
- 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
(Notice there have been good causes to not use multi-release jars, in case you had 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 initiatives). We’ve an (nearly) zero dependency coverage, which we can not comply with 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 believe?). JAXB didn’t appear to be a dependency when jOOQ began out, however it successfully was.
So, the way forward for jOOQ will finally do away with these dependencies the place potential, or transfer them into non-compulsory plugin modules.
