Quarkus 1.1.1.Final released, v1.2 coming with GraalVM 19.3 support

We’ve been watching Quarkus closely, and for good reason – we’ve seen for ourselves what it’s capable of and heard from many Java experts that it’s one to watch. Since it’s been the holidays and we had our feet up in front of the fire, we missed a couple of pieces of Quarkus news. In this article we’ll catch up to the current state of affairs!

Quarkus 1.1.1.Final

Two days ago on Tuesday January 7th, Quarkus 1.1.1.Final was released. This minor release isn’t too much to write home about, consisting of some minor issues being fixed, improvements to documentation, and a spit and polish for Kotlin support. For the inquisitive among you, the changelog can be found here.

The reason why so many fixes were necessary is because of what happened just before Christmas.

Quarkus 1.1.0.Final

On December 23rd last year, Quarkus 1.1.0.Final was released, bringing some pretty big changes to the framework. These are summarized below, but the biggest change and seemingly the one responsible for some interesting feedback mentioned by Guillaume Smet in his blog post is the upgrade to Gradle 6 that happened with this big release. This means how users declare the Gradle plugin needs to be changed. They helpfully provided a migration guide and mentioned that from now on an explicit ./gradlew buildNative is now necessary to build a native executable.

One new addition was Qute, a build time template engine. It’s still in the experimental phase, but they have an introduction guide to get you started.

They also made some configuration framework changes, fixing a number of known issues when dealing with environment variables. The update also introduced YAML support for Quarkus. If a user adds the config-yaml extension, Quarkus will consume the application.yaml file.

SEE ALSO: Java retrospective #3 – most important thing for the community in 2019

There were a few more changes and updates, which you can read more about on the Quarkus blog if you’re interested. The full release notes are on GitHub.

What about GraalVM 19.3?

In version 1.1.0.Final, users were asked to downgrade their GraalVM to 19.2.1. Emmanuel Bernard wrote in a blog post that because of the deep integration between Quarkus and GraalVM it’s an all-or-nothing choice, as they couldn’t support GraalVM 19.2 and 19.3 at the same time. He wrote:

While porting Quarkus to GraalVM 19.3, we hit several regressions, some due to Quarkus not doing the right thing (we fixed them), some due to GraalVM regressions (we are working hand in hand with the GraalVM team to fix them). The next micro bugfix release of GraalVM is planned for mid-January, so any workaround had to come from Quarkus and by writing substitutions.

Even if it wasn’t pretty, the end result was solid enough that we decided to ship CR1 with GraalVM 19.3 support.

And, yet, our 1.1.0.Final is back to GraalVM 19.2. It was a hard decision, believe us, especially with all the work invested to get things ready for 1.1.

Quarkus promises that their ecosystem will work equally well on any JVM and as GraalVM native image executables, and that building native images should be no hassle. The regressions Bernard mentions in the above quote are a concurrency issue that would cause the native image build to randomly fail sometimes, Neo4J no longer working with GraalVM 19.3 and a small number of Apache Camel Quarkus integration tests were no longer able to work in native image mode. However, while these were frustrating, they weren’t enough to tip the scales. The straw that broke the camel’s back was RSS (memory) usage regression.

SEE ALSO: JAX London interview: Quarkus improves the Java development experience

They found that with GraalVM 19.2, Quarkus 1.1 was at 14MB after the first request/response is served. But once they subbed GraalVM 19.3 in, the number jumped more than 400% to 63MB. Keeping memory consumption to an absolute minimum is a core premise of Quarkus, so that’s why it was decided to revert to GraalVM 19.2.

Looking forward, the Quarkus team have worked out a system that should prevent such a situation from happening again – they found this problem very late in the game this time around. Bernard wrote:

We are full steam to bring GraalVM 19.3 support in our next release (and hopefully GraalVM JDK 11 support too). The concurrency issue is already fixed in GraalVM master, that lets us with the low-level issues. Our goal is to help the GraalVM team understand and fix these issues and get all of this backported to GraalVM 19.3.1.

But more fundamentally, we do not want that to happen again: discovering these late in the game is not fun. To be able to catch these issues earlier, we are setting up a set of CI jobs that will check that the whole Quarkus ecosystem (core extensions + quickstarts + Camel extensions + other external extensions) plays well with GraalVM master. This is a bit challenging as it’s (GraalVM) master on (Quarkus) master on (Apache Camel Quarkus) master, but that’s the only way forward. We have the CI job testing our QuickStart suite with Quarkus master and GraalVM master already.

Quarkus 1.2 should arrive later in January and will apparently have lots of exciting stuff. While we wait, why not read more about the GraalVM issue here.

The post Quarkus 1.1.1.Final released, v1.2 coming with GraalVM 19.3 support appeared first on JAXenter.