Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Quarkus, a Kubernetes Native Java Framework, Reaches Version 1.0: Q&A with Thomas Qvarnstrom

Quarkus, a Kubernetes Native Java Framework, Reaches Version 1.0: Q&A with Thomas Qvarnstrom

Leia em Português

Key Takeaways

  • Quarkus is a Kubernetes native Java framework which offers fast startup time and low memory consumption.
  • Quarkus aims to bring Java into the cloud native development era.
  • Quarkus provides the reactive and imperative programming model, leverages a series of libraries already used by the community such as, Vert.x, Hibernate, and MicroProfile.
  • Quarkus is designed to work with GraalVM, and allows developers to build native binaries.

Quarkus, a Kubernetes native Java framework tailored for GraalVM and OpenJDK HotSpot, has reached version 1.0. Quarkus aims to bring Java into a cloud-native application development future and enable it to become a leading platform for serverless, cloud and Kubernetes environments, offering developers a unified reactive and imperative programming model.

Quarkus brings a full-stack framework by leveraging a series of libraries used by Java developers, such as Eclipse MicroProfile, and Vert.x. Quarkus dependency injection is based on CDI, enabling developers to use JPA/Hibernate, JAX-RS/RESTEasy, and more. Furthermore, Quarkus includes an extension framework that third-party framework authors can leverage to extend it; this extension framework also helps developers write extensions that compiles to a GraalVM native binary.

In the cloud era, where containers, Kubernetes, microservices, functions-as-a-service (Faas) and cloud native applications are delivering higher levels of productivity and efficiency, Quarkus emerges as a very interesting alternative.

InfoQ spoke with Thomas Qvarnstrom, senior principal product manager at Red Hat, in order to learn about the Quarkus journey, backwards compatibility, extensions, and the future direction of the project.

InfoQ: Quarkus, first released just this past March, is a very young framework. Can you share your journey from the first release to version 1.0?

Thomas Qvarnstrom: For several years now Red Hat has been researching how we can improve Java in the container, driven by our large investment in and customer adoption of Kubernetes and Red Hat OpenShift. Initially, we focused on improving the Java Runtime (JVM) itself and our Middleware libraries, and most of that work has been made available in OpenJDK and the other upstream communities. In the case of OpenJDK, Red Hat started with Java 11 and also backported those improvements to Java 8, improving performance and lowering memory usage. However, some of the most important features of the JVM, like run once and deploy anywhere, as well as the dynamic discoverability happening at runtime, don't make sense for an application that is deployed into an immutable container.

When running outside of a container and with almost unlimited access to memory, the overhead of the dynamic discoverability was never really an issue, and these features are used in a lot in frameworks like CDI and Spring DI. However, the later years' trends of containers and distributed architectures being the overhead of these frameworks has become a problem. There have been new frameworks and runtimes the last few years, but most simply layered on top of the existing stack (JVM, frameworks, application). We had to entirely rethink the stack to make Java a first-class citizen on Kubernetes. At Red Hat, we had been experimenting with different techniques, like ahead of time (AOT) compilation optimization and compiling byte code to a native executable, for a while. In 2018 we started an internal research project to see how we could combine these efforts. One of the most important requirements going into that was to not require a total rewrite of existing frameworks.

The Quarkus extension system was designed to allow existing frameworks to optimize both their JVM runtime footprint as well as solve the limitation of compiling Java code to a statically linked native executable. At the same time, another open source project, GraalVM, started to gain traction, and part of that was a native compiler. However, one of the drawbacks with a native executable created with GraalVM was that it didn't support the runtime dynamic behavior of the JVM most popular Java frameworks used. Using the Quarkus extension system to optimize frameworks, we were able to quickly port popular frameworks like Hibernate (JPA), RESTEasy, CDI, Camel, Narayana (Transaction), Undertow (Servlet and Web), Vert.x, and Eclipse MicroProfile. Based on the success of the research project, Red Hat created the Quarkus open source community project. The low memory usage and fast startup times were only some of the benefits gained with Quarkus. Quarkus also initially included other benefits, like a live coding experience where developers can keep on working without having to wait for redeployment, and the combination of reactive and imperative programming.

In the last eight months Quarkus has had tremendous success, and the original 8-10 extensions have now grown to 80 different extensions, including things like Kafka clients, OpenID Connect, MicroProfile APIs, Spring APIs, etc.

InfoQ: Now that Quarkus has reached version 1.0, can developers expect backwards compatibility? Are there plans to maintain backwards compatibility for future milestone releases?

Qvarnstrom: We want to balance between innovation and backward compatibility. Both are important to users, but you cannot introduce new features without sometimes replacing legacy. Before 1.0, we never really separated changes that we knew would break backward compatibility from other non-breaking changes. With 1.0 we will be more careful not to introduce changes that we know will break users' application and wait with those changes until the next significant release. However, the Quarkus community's focus is still around innovation, and we expect approximately the same release cadence as before 1.0. To help the ecosystem mature, we have introduced the notion of extension status: preview or stable. An extension marked preview will be free to break compatibility as needed, whereas stable extensions will maintain backward compatibility.

From a user's perspective, backward breaking releases will be more clearly communicated and they will be rarer. Of course, when Quarkus is productized, there will be a published product lifecycle with backwards compatibility commitments.

InfoQ: Earlier this year at QCon SP 2019, Sanne Grinovero gave a presentation on Quarkus, and talked about some restrictions regarding Reflection and I/O. Can you please explain in more detail some of these restrictions in Quarkus? What are your plans to resolve these in the future?

Qvarnstrom: Sanne talked about restrictions in producing a native executable using, for example, GraalVM, especially when compiling a framework that relies on the dynamic discovery of classes, config, etc from the JVM. Sanne also showed how cumbersome and complex it is to overcome some of these issues without Quarkus. Quarkus not only helps overcome the limitations of running java as a native image, but also embraces these limitations, making it easy to solve them in a way that produces an ultra-efficient application regardless if you run it on Java or as a native executable.

InfoQ: There are more than 80 optimized Java framework extensions that support compiling an application to a native binary. In your opinion, what extensions should every developer know about?

Qvarnstrom: One of the major benefits with Quarkus is that developers don't have to learn new APIs since most of what they have been using before can be used without changes. For this reason, developers can become immediately productive. Quarkus has however adopted and innovated beyond the previously known APIs, including things like Panache, an improvement on top of JPA that enables the active record pattern.

Another innovation is MicroProfile Reactive Streams which were first implemented in Quarkus/SmallRye and then pushed back into the MicroProfile community. The extension capability itself is also interesting and enables users to create their own extensions, which is of use for larger development organizations where common patterns based on code and configuration can be shared between teams as extensions.

InfoQ: In particular regarding extensions, Hibernate is a well-known ORM framework, and we know that a lot of work was necessary in order for Hibernate to be ready for Quarkus. Can you share what kind of changes were necessary?

Qvarnstrom: Besides using the extension system to work around the issues discussed above, the Hibernate team also spent a lot of work moving most of the work that was previously done at startup to instead be done at build time, resulting in much faster boot time and reduced memory footprint.

InfoQ: What are the main challenges in continuously evolving Quarkus? Have you been receiving many extensions submissions?

Qvarnstrom: There are a number of extensions to which external developers have been contributing but which then have been optimized by Red Hat developers. Like many communities, the right to actually approve code changes (pull requests) in Quarkus is based on a trust model, based on prior history of contributions, before a person is given access rights to accept code changes. During the last couple of months, we "promoted" external contributors to be able to review and approve changes. This is a major milestone, and for us a sign of the community maturity.

A challenge of the exploding extension ecosystem is verifying the quality of extensions. For that, we are looking into a grading system so that end users can see the quality before adding it to their applications.

InfoQ: What is on the horizon for Quarkus? Is there a roadmap you can share?

Qvarnstrom: Growing the already healthy ecosystem of extensions as user needs are identified. We are looking into adding more extensions like Spring Security, Spring Config, gRPC client/server, additional JDBC clients, additional NoSQL clients, a view templating engine, improvements to reactive programming APIs, reactive Panache, improved observability, and CLI tooling, etc. We are also looking into an improved developer experience for container orchestrated development, where we are investigating expanding on top of the live coding feature to provide a way to do remote live coding directly into a container. But all of that is being discussed by the community as we speak.

InfoQ: Is there anything else you'd like to say to InfoQ's readers?

Qvarnstrom: If you haven't yet, please visit and try it out for yourself. Many users starts by building an application using framework APIs they are already familiar with, like MicroProfile, Vert.x, and Spring Boot. They are often pleasantly surprised by how quickly they become productive with live coding, how fast it starts, and how little memory it uses, and the richness of the extension eco-system. Also, please share your experience - good or bad - on

About the Interviewee

Thomas Qvarnstrom is the senior principal product manager for Runtimes Middleware, Red Hat. He has been with Red Hat since 2007, holding various roles within the Red Hat JBoss Middleware group. Thomas is based in Sweden. Find him on Twitter at @t_millstream.

Rate this Article