[ad_1]
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 whole:
- JAXB – That is fairly the ever-present dependency in jOOQ, and it’s the one we’ll talk about largely on this weblog submit. It’s utilized by the jOOQ runtime and code technology modules, and it presently isn’t optionally available (no less than the API must be current).
- JPA – That is an optionally available 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 provided that Spring Boot 3.0 will migrate as nicely, and quickly eliminated jOOQ from their growth builds (see spring-boot#28821), I assumed we would as nicely migrate now.
What does the migration imply for jOOQ, particularly?
JAXB
JAXB is the largest Java EE dependency, and in addition the one we will’t eliminate simply. At the least not of the API. There are 3 in style XML codecs which are presently marshalled and unmarshalled utilizing JAXB:
Particularly, the code technology configuration’s JAXB annotations are very helpful, as customers can merge XML information with programmatic code technology configuration simply. Additionally, the favored gradle-jooq-plugin third occasion contribution by Etienne Studer works by introspecting the annotations.
Because of the mess created by the JDK 11’s elimination 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 remains to be obligatory, and as mentioned right here, it appears we will’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 based mostly mapping for many 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 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 problem could also be a tipping level in favour of eradicating them finally. The choice has not been made but, however this space is actually not the place jOOQ generates most worth.
Bean validation
We don’t implement bean validation, nevertheless it has at all times been a low hanging fruit to generate a couple of bean validation annotations on generated POJO lessons in jOOQ, simply to counterpoint 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 challenge (solely your generated code does, and provided that you choose in to this), this concern isn’t actually affected a lot by the migration to Jakarta EE
Backwards appropriate 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 neglect 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 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 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 could be clear and permit for customers to determine on their very own what to do. That is what many different initiatives did, e.g. Hibernate. However those that did this had a robust 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).
Moreover, jOOQ already has a ton of distributions, which you’ll see on the downloads web page: https://www.jooq.org/obtain/variations.
We’ve got:
- 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
(Word 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 an excellent larger ache for a library like jOOQ (due to the ache it causes in consumer initiatives). We’ve got an (virtually) zero dependency coverage, which we can’t 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, nevertheless it successfully was.
So, the way forward for jOOQ will finally eliminate these dependencies the place potential, or transfer them into optionally available plugin modules.
[ad_2]
