First introduced to the Java community in 2018 and 2019, Quarkus, Helidon and Micronaut embarked on a journey to provide alternatives in a market dominated by Jakarta EE and Spring. Their main differentiator: the cloud-native promise in a world that has been rapidly moving to the cloud. In 2022, Java’s intent to be cloud-fit was underlined: Project Leyden was resurrected to continue its mission to have a Java presence in the cloud, and the release of Spring 6.0 made the first steps towards supporting native Java.

Quarkus seems to have a head start, as its guiding principles, stated on its website, include:

• Framework Efficiency: "promising supersonic, subatomic with fast startup and low memory footprint"
• Kube-Native: "enabling Java developers to create applications that are easily deployed and maintained on Kubernetes"

Quarkus’ continuous evolution seems to be confirmed by its "Early Majority" classification, according to the December 2021 InfoQ Java Trends Report, and by being shifted to the "Trial" bracket, according to October 2021 ThoughtWorks Technology Radar. Following its traditional major release every 18 months, the framework has reached its next major version promising additional improvements towards its stated mission.

To get a deeper understanding of what developers can expect in the final version 3.0 release targeted in the next couple of months, InfoQ reached out to the team behind the project led by Max Rydahl Andersen, Quarkus co-lead and distinguished engineer at Red Hat. This is the first of a two-part news story that discusses the road to Quarkus 3.0.

InfoQ: Thank you for taking the time to answer the questions for our readers. To start: what are the major themes for Quarkus 3.0?

Max Rydahl Andersen: This is an ever-evolving list that changes based on the community’s feedback while getting closer to the final version. Currently, the major themes are the integration of Hibernate ORM 6, Eclipse MicroProfile 6, virtual threads and structured concurrency following the learnings from the initial integration. Also, we target some core changes to improve performance like bringing io_uring (next generation async IO) and moving from Reactive Streams to using the Flow API.

InfoQ: Why does Quarkus 3 switch from Reactive Streams to Java’s Flow API?

Julien Ponge: We created SmallRye Mutiny for reactive programming, initially being developed on top of the Reactive Streams API. The implementation decisions were made when Java 8 was still supported and the Flow API was not part of the JDK. That is no longer the case, so we decided to embrace modern APIs. Mutiny 2 was conceived with this thought in mind. However, as that larger migration in the ecosystem may take time, Mutiny provides no-overhead adapters to bridge between Java Flow and the legacy Reactive Streams APIs. To make the transition smoother, Resteasy Reactive and Reactive Messaging work with both.

InfoQ: Project Leyden plans to optimize Java with jlink enhancements. Does Quarkus plan to support the Java Platform Module System (JPMS)?

Andersen: The limits applied by JPMS hinder the experience frameworks and users have. Therefore we hesitate to support JPMS fully as it hurts both usability and performance.

We are happy to see ideas being explored around the condenser notion in Leyden. This would allow the JDK and third-party libraries and frameworks to participate in various phases of the creation of an optimized Java application and eventually native image generation. Nevertheless, it is proposed to be done via jlink. We are working with OpenJDK and GraalVM to find a solution not to exclude the vast majority of the java ecosystem relying on classpath-based libraries.

GraalVM native images have shown that dead code elimination works remarkably well to decrease storage and provide runtime savings; without being limited to JPMS boundaries.

InfoQ: Are there any particular features that you would encourage developers to use with care?

Andersen: In general, we expect everything to work after the initial migration step, but when using Apache Camel, it is recommended to wait for version 4 when the Jakarta namespace will be supported.

We wish that would not be a necessity, but that ship has sailed, and now we focus on a smooth transition. We focus on having minimal breakages in our core and providing migration tooling.

InfoQ: What was the most challenging technical aspect while developing this version?

Andersen: Even though "boring", the Jakarta namespace migration was a multi-year effort that involved close collaboration with multiple Red Hat Runtimes teams. Before even considering moving Quarkus to the Jakarta namespace, we ensured that the underlying stack was ready. Once the releases started happening, we started working on a semi-automated way to have our current Quarkus release and validate as many extensions as possible.

According to Andersen, Quarkus was created to enable the use of Java in container-native applications and, in doing so, rethink the approach the Java ecosystem has taken over the last quarter of a decade. More than just efficient running, Quarkus focused on Developer Experience (DX) as well: hot code replacement, continuous testing and developer services. All in all the effort to make a cleaner API to deliver business applications faster. As they try to work closely with the community, developers are encouraged to try it and provide feedback.