Drop support for jOOQ until its JAX-B dependency is Jakarta EE 9 compatible

[wilkinsona]

jOOQ/jOOQ#9641

[lukaseder]

Hi there! 👋 I guess that increases the pressure of actually doing that 😅. I'll ping you here when it's done. Release 3.16 is due for the end of the year.

[wilkinsona]

Please don't feel pressured, @lukaseder. 3.0's going to have a long release cycle with GA currently planned for November 2022.

[lukaseder]

Yeah, no, I promised this already to a few folks, so a good reminder to push this. Shouldn't be too much effort as jOOQ isn't using much of JavaEE / Jakarta (ideally, just a dependency change and package update).

I'm in the mood for busywork this week, now that H2 already broke pretty much everything: jOOQ/jOOQ#9609

[lukaseder]

I mean... upgrading the dependency (and removing the old one) won't be a problem for Spring Boot 2.x?

[wilkinsona]

Spring Boot 2.x is stuck on jOOQ 3.14 by default due to 3.15's move to Java 11 by default.

For Boot 2.x users that want to upgrade jOOQ's version, switching to the jakarta.xml.bind.* classes may cause problems if other parts of their app use javax.xml.bind.*. This is compounded by the fact that the jakarta.xml.bind:jakarta.xml.bind-api coordinates can provide either the jakarta.* classes or the javax.xml.bind.* classes depending on the version you use. This makes it hard to have both on the classpath if that's something you can tolerate.

From what I've seen while working on our Jakarta EE 9 upgrade, projects seem to be taking one of two approaches:

1. Alongside the existing modules, start publishing -jakarta variants of their modules that contain rewritten bytecode to switch to the jakarta namespace. Undertow and Hibernate have both taken this approach, for example
2. Double your maintenance burden by releasing a new major version that switches to EE 9

If your project is only making very light use of Jakarta EE, I'd strongly encourage considering a third option where you drop the dependencies altogether. The transition from EE 8 to EE 9 feels like it is going to take quite a long time and it's only with EE 10 that new features will arrive and users will benefit from it. If there's a possibility of getting jOOQ into a position where it doesn't matter how long the transition takes across the whole ecosystem, I'd grab it with both hands. Unfortunately, that's not possible for many parts of Spring where we heavily depend on the Servlet API, JPA, etc.

[lukaseder]

So jOOQ/jOOQ#9609 is integrated in jOOQ 3.16, which no longer uses the javax namespaces.

Spring Boot 2.x is stuck on jOOQ 3.14 by default due to 3.15's move to Java 11 by default.

Right, I forgot

This makes it hard to have both on the classpath if that's something you can tolerate.

These APIs have almost no use within jOOQ, so there's little value of supporting both in parallel. I did expect trouble elsewhere in case both are on the classpath, which is why I implemented the above jOOQ/jOOQ#9609 as a breaking change in 3.16. I'll document this accordingly. Few jOOQ users use these dependencies in jOOQ, they're declared optional, and users can use Maven or Gradle to exclude them from jOOQ's transitive dependencies, if they don't need them.

If your project is only making very light use of Jakarta EE, I'd strongly encourage considering a third option where you drop the dependencies altogether

I do have plans of:

• Moving the JPA dependency out into a separate module (I'm really just re-using their annotations for "convenience". I could have rolled my own). That will allow me to let the module "die", because I'm not too fond of this feature
• Removing the JAXB dependency, because I've already rolled my own implementation of JAXB for the purposes I needed, in case an implementation is absent on the classpath, which has been a problem for many users since JDK 11. But there's still the dependency on the JAXB API. I'm not sure if that can be removed easily.

So, this is an option for the future, but not too soon.

Given that both dependencies are optional, and most users don't need them, I think:

1. Is too excessive in jOOQ's case. There are already -trial, -pro variants as well as -java-8, -java-11 variants. Duplicating variants with a -jakarta suffix seems overengineered (in jOOQ's case). It's obviously different for Hibernate, because they really implement JPA. jOOQ doesn't.
2. Yeah, that's what this will be about, I guess. With Spring Boot 3.0's bold new baselines, I'm positive that things will speed up a bit.

[lukaseder]

So jOOQ/jOOQ#9609 is integrated in jOOQ 3.16, which no longer uses the javax namespaces.

N.B: I'll ping you again on this issue here once jOOQ 3.16 is released.

[lukaseder]

jOOQ 3.16.0 including jOOQ/jOOQ#9641 has been released and the javax dependencies have all been replaced by their equivalent jakarta dependencies, see: https://blog.jooq.org/3-16-0-release-with-a-new-public-query-object-model-api-spatial-support-yugabytedb-support-and-much-more

Let me know if you need any additional information, and I'll be very happy to help.

[wilkinsona]

Thanks, @lukaseder. I've opened #29271 to reinstate support by upgrading to 3.16.