Upgrading Java & JOOQ: Issues and Resolutions

by

Java & JOOQ is an excellent combination to handle and query the application data. Until recently, my project was running on OpenJDK 1.8.0_321 and JOOQ 3.13.2 libraries and it worked just fine. But, due to organizational push for newer and stable versions of Java & JOOQ, we needed to upgrade them.

So, it was decided to go with Java 17 as it’s the long-term support (LTS) release, meaning it will get updates and security fixes for years to come. It brings modern language features like sealed classes, pattern matching, and text blocks, while also improving performance and memory usage.

Also, I picked JOOQ 3.19.7 for jooq upgrade, which builds on these advancements with better SQL generation, support for more databases, and various quality-of-life improvements for developers.
If you want cleaner code and faster builds, the upgrade is worth it.

That said – not everything works perfectly right after upgrading.
When I moved one of my projects to OpenJDK 17.0.15 and JOOQ 3.19.7, a few annoying issues came up.
Here’s a step-by-step explanation of what broke, and how I fixed it.

1. Text blocks are not supported in -source 8

After the upgrade, JOOQ’s Maven plugin regenerated my views using Java text blocks, which require Java 15+. The compiler, however, was still treating the source level as Java 8.

Fix:
Update the language level in IntelliJ (or your IDE of choice):

  1. Right-click the project → Open Module Settings.
  2. For a module:
  • Go to the Sources tab.
  • Set Language level to Project Default or 15 – Text blocks.

3. Repeat this for all modules.

2. Update the Maven Compiler Plugin

My project had the source set to version 8, to ensure Maven compiles with Java 15+ features, update your parent pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>${plugin.maven-compiler.version}</version>
    <configuration>
        <source>15</source>
        <target>15</target>
        <useIncrementalCompilation>false</useIncrementalCompilation>
    </configuration>
</plugin>

This aligns your Maven build with your IDE’s language level.

3. The reference to “Record” is ambiguous

As we know with Java 16+, java.lang.Record became a standard class – and it clashes with JOOQ’s Record interface.

Fix:
Explicitly import JOOQ’s version in every class that uses it:

import org.jooq.Record;

This makes the compiler pick the right one.

4. Add/Update the WAR Plugin

When the maven-war-plugin version was set to 2.3 in my project, i observed the below error while building the app. This error basically tells us that there is JDK version mismatch.

Error injecting: org.apache.maven.plugin.war.WarMojo
com.google.inject.ProvisionException: Unable to provision, see the following errors:

1) Error injecting constructor, java.lang.ExceptionInInitializerError
  at org.apache.maven.plugin.war.WarMojo.<init>(Unknown Source)
  while locating org.apache.maven.plugin.war.WarMojo

1 error
    at com.google.inject.internal.InternalProvisionException.toProvisionException (InternalProvisionException.java:226)
    at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
    at com.google.inject.internal.InjectorImpl.getInstance (InjectorImpl.java:1086)

To resolve this, upgrade the maven-war-plugin version in your parent pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>3.3.1</version>
</plugin>

This ensures smooth WAR packaging after the upgrade.

Final Thoughts

Upgrading to Java 17 and JOOQ 3.19.7 can give you cleaner syntax, better performance, and a more future-proof codebase. But it’s not always a plug-and-play process – text block support, compiler configuration, and naming conflicts can cause headaches.

Follow the fixes above, and your upgrade will be much smoother. Please explore more of these interesting topics Here. Happy programming!!

References:

Maven war plugin

Change language level

Leave a comment