Use and require Java 22

[mosabua]

This issues aims to detail and track the progress towards adopting Java 22 as build and runtime requirement for Trino.

Background and motivation

Trino completely adopted Java 21 as of Trino 436. See https://trino.io/blog/2023/11/03/java-21 and https://trino.io/docs/current/release/release-436.html. Java 21 is a LTS release of Java.

Java 22 brings considerable improvements and additional APIs that enable further progress in terms of performance work done in Project Hummingbird.

Java 22 is a STS Java release and scheduled to ship in March 2024. Adoption timing in Trino will depend on testing results and feedback, as well as the time for implementation and collaboration with Trino community members.

Specifically, for Java 22, these are some features that we want to be able to leverage:

• https://openjdk.org/jeps/423: Region pinning for G1
• https://openjdk.org/jeps/454: Foreign Function & Memory API
• https://openjdk.org/jeps/456: Unnamed Variables and Patterns
• https://openjdk.org/jeps/457: Class File API
• https://openjdk.org/jeps/459: String templates
• https://openjdk.org/jeps/460: Vector API
• https://openjdk.org/jeps/462: Structured Concurrency
• https://openjdk.org/jeps/464: Scoped Values

Implementation

Following steps are roughly in order:

• CI build with Java 22 EA in parallel to Java 21
• Blog post about plan to adopt Java 22, @mosabua and @dain, https://trino.io/blog/2024/03/13/java-22
• Update dependencies as required to support Java 22, @wendigo
• Update JVM in docker container to Java 22, @wendigo
• Wait for official release of Java 22 and Eclipse Temurin binaries (if necessary in terms of timing)
• Ship a release with the updated container image, and solicit user feedback - done with Trino 444
• Update build, docs, and runtime to require Java 22, PR from @wendigo ready
• Ship Trino 445
• Ship Trino 446
• Merge PR to require Java 22
• Announce for developers
• Ship Trino 447, announce, and update blog post

[wendigo]

Related: mojohaus/extra-enforcer-rules#286

[wendigo]

We also need modernizer 2.8.0 which currently breaks mvnd support. With these two plugin changes and some airbase updates, master builds on JDK 22-ea (22.ea.36) with language level 22.

[wendigo]

✅ Related: airlift/airbase#397

[wendigo]

✅ Related: #20986

[wendigo]

✅ Related: airlift/airbase#402

[wendigo]

✅ Related: #21155

[wendigo]

✅ #21161

[wendigo]

✅ Docker switch to 22 along will all the tests: https://github.com/trinodb/trino/pull/21161/files

[wendigo]

Master is switched to 22 in the runtime

[wendigo]

Final piece - require JDK 22 and switch language level to 22: #21279

[wendigo]

@mosabua first release shipped with JDK 22 in the runtime

[mosabua]

https://trino.io/docs/current/release/release-444.html#docker-image

[mosabua]

#21675 is ready to go.

[mosabua]

https://www.linkedin.com/feed/update/urn:li:activity:7191536752916881409

and

https://trinodb.slack.com/archives/CFLB9AMBN/p1714595878079299

[mosabua]

PR is merged. Java 22 will be a requirement for Trino 447 and newer.

[wendigo]

447 was released.

[mosabua]

Copying here for reference and other readers

Questions from @covalesj:

Just a note -- jdk22 is a short term release; depending on that is going to cause issues in some enterprise environments that only stick to LTS versions of java. Only a problem if jdk22 features begin to get baseline, which will result in forcing longish upgrade cycles for enterprise customers.

Answer from @mosabua reprensenting the Trino project:

We are aware of that. However the benefits outweigh these issues. We will continue to stay with the latest Java release going forward. What JDK is used is mostly an implementation detail. Especially in container-based deployments there is no impact. For non-container based deployments users will just have to choose to stay with old Trino and old Java .. or go with new features, more performance, timely security fixes, bug fixes and overall improvements all around.

Also keep in mind that the "support" window for Java release is completely variable between vendors and you can get support for any release. We are using Eclipse Temurin as an open source project for our testing and inclusion in the container.

[mosabua]

Final update on blog post - trinodb/trino.io#658

Announcement for release https://trinodb.slack.com/archives/CFLB9AMBN/p1715275120439609

[covalesj]

Typically an enterprise may have to build their own container images, with any custom connectors built under a enterprise supported JVM and and JDK. Development teams typically don't get a choice for JVM, but a enterprise wide supported version and release cycle. It sounds like in that case, their enterprises would have had to adopted and rolled out base images to support java 22 within 4 weeks of it being launched (and also support STS). It's likely that they have to forego new features in that case, specifically to meet security and compliance standards (eg.. SOX 2, PCI etc.) and will have to wait until a new LTS is available... or they have to to recompile and back out any specific use of java 22 features that break compilation. Which is the route we will be forced to take if we want to upgrade. Typically we stay within 1 month... but in this case, given those restrictions, and the new LTS for an oracle jdk being in 2025... it will be... something more than a year before we could directly use the baseline without maintaining a backport. I am going to guess that Starburst will run into this sooner or later.

[mosabua]

For the Trino project we decided to move forward for the various reasons mentioned earlier and in the blog post announcement from March - https://trino.io/blog/2024/03/13/java-22

The move has been in planning ever since we moved to 21.

Backporting will be something that some might attempt but I have a feeling this is going to get very difficult soon. We plan to use foreign function and memory API and other newer features and this will result in complex and often impossible situations.

Starburst and all vendors have to decide what they want to do themselves, but I would strongly suggest to all of them to just move on and with the times. Users that want to stay with old releases can always do that.