GitHub user aglinxinyuan created a discussion: Proposal: Move the build & runtime from Java 17 to Java 21
## The problem jOOQ's **Open Source Edition tracks the latest LTS JDK**: from **3.20 onward its jars are compiled to Java 21 bytecode** (class file version 65). We build and run on **Java 17** (class 61) across every CI matrix, so anything ≥ 3.20 compiles fine (scalac happily reads the newer class files) but blows up the moment a JVM actually *loads* a jOOQ class. Concrete example — **#6225**: Dependabot bumped `org.jooq:jooq` to 3.21.6 and CI went red at *test runtime*: ``` java.lang.UnsupportedClassVersionError: org/jooq/Table has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0 ``` on `build / amber-integration` and `build / platform (computing-unit-managing-service)`. I capped it at **3.19.36** — the last jOOQ release that still targets Java 17 — to unblock, but that's a dead end: **every jOOQ update past 3.19 is now blocked** until we move off Java 17, and the same wall will hit other libraries as they raise their baseline to 21 (the ecosystem is steadily moving there). ## Proposal Move the project's build and runtime from **Java 17 → Java 21** (the current LTS). Roughly touches: - **CI:** `java-version` / matrix in `.github/workflows/build.yml`, `benchmarks.yml`, `build-and-push-images.yml` (17 → 21). - **Build:** `javac` / `scalac` release target in `build.sbt` (and confirm our Scala 2.13.x patch is one that fully supports JDK 21). - **Docker:** base JDK images in the engine/service Dockerfiles (`eclipse-temurin:17-*` → `21-*`). - **Docs:** the setup guides that reference JDK 17. Payoff: unblocks jOOQ 3.20+/3.21+ (and future bumps that assume a 21 baseline), while keeping us on a current, long-supported LTS. To be clear on urgency: Java 17 is **not** EOL, so there's no fire — but the library floor is rising and #6225 is the first place it's actively costing us. This is also bigger than a dependency bump: it needs a green run across the engine, all Scala services, the Python-worker interop path, and the published Docker images. Raising it here before scoping a PR — thoughts / objections? GitHub link: https://github.com/apache/texera/discussions/6248 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
