[ad_1]
A tidal wave is rippling via 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 complete:
- JAXB – That is fairly the ever-present dependency in jOOQ, and it’s the one we’ll focus on principally on this weblog publish. It’s utilized by the jOOQ runtime and code technology modules, and it at present isn’t non-compulsory (at the least 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 Problem #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 growth builds (see spring-boot#28821), I assumed we’d as effectively migrate now.
What does the migration imply for jOOQ, particularly?
JAXB
JAXB is the largest Java EE dependency, and in addition the one we are able to’t eliminate simply. Not 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 technology configuration’s JAXB annotations are very helpful, as customers can merge XML recordsdata with programmatic code technology 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 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 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 permits 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 could be configured to generate JPA annotations on generated POJO lessons, 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 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 lessons in jOOQ, simply to counterpoint your POJOs with some well-known meta information, similar to e.g. @Measurement for a string. Since we don’t have a tough dependency on this Jakarta EE venture (solely your generated code does, and provided that you choose in to this), this problem 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 overlook about Java EE?
- Ought to we drop help for the integrations?
Clearly, dropping help wasn’t an choice 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 hassle. Not for jOOQ. It could be easy for jOOQ to help each APIs, however having each APIs on all jOOQ person classpaths is simply horrible and would trigger so many points in shopper tasks.
Delivery 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 smart for Hibernate to separate into two distributions. Not a lot for jOOQ, which makes solely marginal use of those APIs (even of JAXB).
In addition to, 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 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 good larger ache for a library like jOOQ (due to the ache it causes in person tasks). We have now an (nearly) 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 feel?). JAXB didn’t appear to be a dependency when jOOQ began out, however it successfully was.
So, the way forward for jOOQ will finally eliminate these dependencies the place potential, or transfer them into non-compulsory plugin modules.
[ad_2]