Red Hat has released Quarkus 3.0, its Java framework for containers and Kubernetes, with this being the version based on Jakarta EE 10. New features include an enhanced Dev UI, a kind of developer dashboard automatically generated during development, and use of Hibernate 6, an upgraded version of the well-known object-relational mapping framework for Java.
Quarkus 3.0 also has new commands, with Maven and Gradle plugins, adding the ability to deploy an application to platforms including Red Hat’s OpenShift as well as generic Kubernetes. There are many improvements to RESTEasy Reactive, which is the default REST layer for Quarkus. Support for a Redis backend has been added, with a Cache extension.
The new release is designed for Java 17 or later. “The OpenJDK community will end active support for Java 11 in September 2023,” said Red Hat’s Guillaume Smet, Principal Software Engineer working on Quarkus and Hibernate. “We still plan to support Java 11 past that date for core Quarkus functionality, but Java 11 is now marked as deprecated.”
There is a detailed migration guide for Quarkus 2.x users but Smet acknowledges that “the update to Quarkus 3.0 will require some work and testing on your side, especially if you are using Hibernate ORM.” Therefore the 2.x series remains supported with bugfixes for “a few months.”
Quarkus 1.0 was released in November 2019, as a Java framework designed for containers and Kubernetes. That goal is achieved in part by optimizing for GraalVM to compile Java bytecode to native binary code. The project is open source under the Apache 2.0 license.
Quarkus 2.0 arrived in June 2021, but the path to the new version 3.0 has been difficult thanks to the transition from Java EE to Jakarta EE, including the package name change from javax to jakarta which required reworking the code. Smet described the transition as “extremely disruptive,” partly because Quarkus does a lot of code generation as well as being a large and complex project.
This is a big new release with a ton of features. The development process benefits from a modern workflow, wide range of extensions, reactive approach and the innovative DevUI; while at runtime the container optimization should mean fast start-up and lower memory consumption, perhaps indicating that more instances can be supported on the same infrastructure, as well as smoother scaling.
The snag is that the dominance of Spring Boot in the Java application world, and its maturity, makes it hard for Quarkus to catch up. Currently Spring Boot benefits from more resources and it will be easier to find developers than for Quarkus. Spring Boot also now supports native binaries via GraalVM, so Quarkus is not distinctive in this respect. There is plenty more to Quarkus though than just GraalVM support making it worth careful consideration.