Quarkus – what’s next for the lightweight Java framework?

With the release of Quarkus 0.20.0, we decided to get in touch with JAX London speaker, Java Champion, and Director of Developer Experience at Red Hat – Alex Soto. He was kind enough to answer all our questions about the past, present, and future of Quarkus. It seems like we have a lot to look forward to with this exciting lightweight framework!

JAXenter: Quarkus is a relatively new framework that promises lightweight development of container-first applications in Java. What is meant by “container first”?

Alex: Container-first means that everything from its beginning is thought to work perfectly inside a container without having problems not related to our application. We worked in two directions:

Firstly, by providing a way to compile an enterprise application into native code. This is very important as it is well-known by the Java community that a JVM program running inside a container can eventually blow up without any obvious reason. The true reason for this crash is related to the fact that Java (and the JVM) was created a long time before Linux (and Docker) containers entered the scene. The JVM at that time didn’t have the notion of a container so the process tried to use as much memory and CPU as the hardware machine was able to provide. So when you put a Java program (especially with Java 8) into a container, it tries to grab as many resources as possible, going beyond the boundaries of the container. When this happens, the Linux kernel stops this container, and thus the process that is running inside it too.

Although this has been improved since then, making Java 11 ready to be used in containers, you still need to know how to do it. Quarkus fixes that problem by providing a way to produce (with Graal VM) a native executable of your enterprise Java application, so you get the same behavior as any other native compiled program written in Go or C++ when they are running inside a container.

The second direction is by not creating a big uber-jar but a small uber-jar to provide fast build time. This feature is useful in case you are not building a native executable but running your Quarkus application (or service) in JVM mode using Java (11). Other frameworks out there have the concept of uber-jar where they bundle the application itself and the required libraries into the output JAR. This is not a problem per se if you are not building a container to run that application, but if you use container technology (Docker), then things become more interesting. When you create a Docker container, the container is generated in layers, so each step used to build the container is stored in a layer that can be reused for other builds.

…two layers are created in the container, one for your code and another one for the dependencies, so any change in your code implies only a small new layer with just the runnable code…

Using the heavy uber-jar means that for any change in your code (just small bits) you are creating a new layer of tenths of megabytes because your application layer is the application and all the dependencies. But Quarkus uses a different approach – we produce two artifacts, one JAR containing the runnable code and another one (a directory) containing the dependencies. What this effectively means is that two layers are created in the container, one for your code and another one for the dependencies, so any change in your code implies only a small new layer with just the runnable code, as the dependencies one is reused from the previous execution.

JAXenter: How did the project come about? Who is behind it – with what motivation and goal was it developed?

Alex: Quarkus is an open source project sponsored by Red Hat but contributed to by several other individuals not related to Red Hat. It came with two main goals: to improve the developer experience when developing microservices, and to make Java a language choice for microservices and serverless architecture.

JAXenter: What are the strengths of Quarkus?

Alex: Well, the answer to this question might vary depending on the role of the reader, but one of the strengths of Quarkus is that it helps you save money. In the past, every company owned the hardware upon which the applications were running, so you spent some money on acquiring it. Nowadays, we are in the cloud era; we do not buy the hardware anymore, but we pay for its usage. The more CPU and RAM memory we need, the more we pay. So these days the usage of CPU and RAM matters. Quarkus in its native mode cuts down the CPU usage (reducing the boot time and time per request) and reduces the memory requirements by 10 in comparison to other traditional Java frameworks. But this reduction is not only in native mode, in cases using JVM, the memory usage is reduced by 2.

With Quarkus and live reloading, you only need to save the change, and this change is almost instantly reflected in the running instance.

One of the most acclaimed features by developers is live reloading. This is something that other languages already have, but it is something really new for Java developers. Live reloading allows you to make a change in any file of your application, for example, a class, without having to recompile or repackage it; these changes are automatically reflected in a running instance of the application. Notice that before this, for a change to be reflected in a running instance you had to compile and package the application, stop the previous instance and restart the whole application. With Quarkus and live reloading, you only need to save the change, and this change is almost instantly reflected in the running instance. No compilation, no repackaging, no restart.

Everything you learn about these specifications in Quarkus can then be used in any other project not based in Quarkus.

Also, the integration with Panache framework is a really big win for developers who write JPA code because it significantly reduces the amount of boilerplate code you need to write in the data access layer.

Last but not least, Quarkus is based on well known specifications such as JAX-RS, JPA, CDI, Bean Validation, and MicroProfile spec. This means that everything you already know about them can be used in Quarkus. The other way around is also true: Everything you learn about these specifications in Quarkus can then be used in any other project not based in Quarkus. This is a really good advantage as you do not really need to learn or investigate how to do things in each of the frameworks you are developing.

SEE ALSO: Jakarta EE & Eclipse MicroProfile – two names, one family?

JAXenter: Version 0.20.0 of Quarkus has just been released. What are the highlights there?

Alex: Yes, this version was released last week, but every 2 weeks a new version is released. For version 0.20.0 we added the next features:

• Hibernate ORM multi-line support in import scripts
• Improved integration of Hibernate Validator with CDI
• New MicroProfile REST Client implementation
• Upgrade to MicroProfile Metrics 2.0
• Configuring a per-method transaction timeout
• Syslog support for logging
• Support for Jackson as marshaler/unmarshaler
• Support for OAuth 2
• A guide on how to deploy Quarkus in Microsoft Azure.

Of course apart from these changes, also the release contains bug fixing, enhancements, and performance improvements.

SEE ALSO: Going native with Eclipse MicroProfile and Quarkus

JAXenter: What are your plans now – what new features and versions are upcoming?

Alex: Well it is an open-source project, this means that version 1.0.0 will be ready when it is ready, but we plan it to have it around within the calendar year. We are very confident of the code quality of Quarkus – if nothing else that the runtime code just calls frameworks that are rock solid (Netty, Vert.x, RESTEasy, Hibernate ORM, Camel, etc.). The reason it is not in 1.0 is that we are not quite ready to cast some of the extension APIs in stone. We are also refining the ecosystem model and want it to be present when 1.0 is released.

In the end, the version number is just a number, we take care of all releases in a way that they are production ready.

That said, we know a lot of companies that are running Quarkus in production. In the end, the version number is just a number, we take care of all releases in a way that they are production ready.

We have got several new features planned for the next releases of Quarkus; we want to continually enhance the developer experience, offering more features that make their day-to-day job a joy. Also, we want to use the Panache “concept” so it can be used for other backends and not just JPA.

We are rethinking the HTTP stack to have a deep integration between Netty, Vert.x, Undertow, and RESTEasy. It’s important ground work that will to significantly improve our unification of imperative and reactive, as well as offer a very useful serverless development experience.

In the same vein, we are unifying the security layers to make them more evolutive and share them across the stack.

And finally, we can expect more and more integrations with existing frameworks like Vault or JMS.

The post Quarkus – what’s next for the lightweight Java framework? appeared first on JAXenter.