Do you ❤️ Trino? Give us a 🌟 on GitHub

Trino blog

News from the community of users and contributors

Blazing ahead with 22


It was not that long ago that we first announced support for Java 21, and subsequently made it a build and runtime requirement with Trino 436.

Since then, the codebase received some significant improvements in readability, and we have also seen better performance. However, innovation in Trino and Java is not holding still, on the contrary - it’s accelerating. On the Java community side, Java 22 is just about to be released, and we think it is time to drive innovation in Trino even further. Trino is going to use and require Java 22 soon!

Background and motivation #

The planned move to use and require Java 22 for build and runtime of Trino is driven by numerous aspects:

  • Take advantage of performance and runtime improvements of the new JVM version.
  • Use the newly available language features to further improve readability and maintenance aspects of the codebase.
  • Enable the use of further performance improvements for Trino under the umbrella of Project Hummingbird.
  • Attract and motivate more contributors for Trino as an opportunity to work with a modern Java stack on a cutting edge, complex application and work with the relevant language features and APIs.

Speaking about APIs and new features, let’s look at a list of JDK Enhancement Proposals (JEPs) that we are actively looking at. Specifically we plan to experiment, and adopt any non-preview JEPs where we see benefits. We also plan to submit any issues and problems we encounter back upstream to the Java community:

  • Region Pinning for G1 (JEP 423)
  • Foreign Function & Memory API (JEP 454)
  • Unnamed Variables and Patterns (JEP 456)
  • Class File API in preview (JEP 457)
  • String Templates in second preview (JEP 459)
  • Vector API in 7th incubator (JEP 460)
  • Structured Concurrency in second preview (JEP 462)
  • Scoped Values in second preview (JEP 464)

Many of these API’s allow us to further modernize the feature set of Trino and adapt it to current hardware and compute power realities. Specifically we can continue with our commitment to the Java ecosystem and avoid many of the complexities and pitfalls of JNI - the traditional, now legacy integrations with native code and specific hardware features.

Another aspect some of you might wonder about is the move from a Java LTS version to a Java STS release – from “long term support” to “short term support”. So far Trino was using Java 8, Java 11, Java 17, and then Java 21 as requirements. Since all of them are LTS releases, some of you might have concluded that we have a policy of only using Java LTS versions. That is not the case, it is only a coincidence.

We always thrived to use up to date source code, dependencies, runtime environments, and so forth. The benefits, including better performance, available and included bug fixes, reduced need for backports, less security issues, and support for modern language features, development environments, and tooling, always far outweighed the effort of staying up to date.

We are now finally at the long planned status where we can move quick enough as a project to use latest tools, dependencies, and Java releases and keep iterating on our frequent releases. And that is exactly what we are doing for the benefit of everyone contributing to Trino and using Trino. Java 22 now. And then later this year we can move to Java 23, and next year to 24 and 25.

So what are we specifically doing now?

Current status and plans #

Java 22 is scheduled to ship in March 2024. The various JDK distribution binary packages will become available shortly after the official release.

Early access source and binaries are already available, and our continuous integration builds already use such an EA build successfully.

Overall the transition is going well. Our plan is to follow the same approach as our switch to Java 21:

  • Ensure everything works with Java 22.
  • Change the container image to use Java 22.
  • Cut a release and get community feedback from testing with the container.
  • Adjust to any feedback and available improvements for a few releases.
  • Switch the requirement for build and runtime to Java 22.
  • Cut another release and celebrate.

And then the real fun starts all over. We can update code, libraries, and start working with the new APIs. Timing on all the work depends on obstacles we find on the way and how we progress with removing them.

We use the Java 22 tracking issue and the linked issues and pull requests to manage progress, discuss next steps, and work with the community.

Feel free to chime in there or find us on the #dev channel on the Trino community Slack.

Join us in this exciting next step for Trino.