Quarkus 3.14 - Hibernate ORM 6.6, Let's encrypt, faster reflection-free Jackson serializers...

We announced it already, the next LTS version of Quarkus will be Quarkus 3.15.

It will be branched directly from the 3.14 branch and will be the direct continuation of our 3.14 work.

So don’t expect new features in 3.15, we will focus on bugfixes.

We upgraded the Hibernate stack to the latest and greatest:

Given it’s new minor versions coming with new features and some behavioral changes, we highly recommend to have a look at the Quarkus 3.14 migration guide if you are using the Hibernate stack in your Quarkus applications.

Thanks to a contributor who provided a large entity model under an Open Source license, we were also able to optimize the Hibernate ORM bootstrap for large models and you should see significant improvements in the Hibernate ORM boot time if you have a large entity model.

The TLS registry we introduced recently has gained easy management of Let’s encrypt certificates, in part thanks to a nice Quarkus CLI plugin allowing to generate Let’s encrypt certificates.

Learn more about it in our TLS registry reference guide.

We all love our code running fast. And Jackson default serialization, while very efficient, is using reflection which introduces some overhead.

In Quarkus 3.14, you have the ability to generate faster reflection-free serializers for the the types that will be serialized by Quarkus REST. Jackson has a ton of features and not all of them are supported but this new feature is smart enough that it default to standard Jackson serialization if your classes are using Jackson features we don’t support.

This option is still experimental and disabled by default but we would love for you to test it and report back (does it work for you? do we need to add one more feature for you to be able to use it?). You can find more information about it in the REST reference guide.

You know we are very concerned about the Dev Experience with Quarkus. A part of this amazing DevEx is the Quarkus CLI, that brings more and more features with each version.

In 3.14, we introduced a gRPC CLI plugin, which may make your life a lot better if you are using the Quarkus gRPC extensions.

You can see some examples of how to use it here.

We updated the default UBI images to 1.20/8.10.

When you are using dev mode, we try hard to make the stacktraces as meaningful and helpful as possible.

In Quarkus 3.14, they are now decorated with more context, allowing to jump more quickly to the source of the problem.

This was a popular request and we now provide an easy way to execute some code after the HTTP server is started.

You can find out all about it in the HTTP reference guide.

Some OIDC providers returns the UserInfo as a signed JWT token. This is now supported transparently by Quarkus.

We updated the MongoDB client from 4.11.x to 5.1.x.

This is only of interest for extension developers but the extension annotation processor has been rewritten to have a cleaner architecture, especially for everything that concerns the generation of the configuration properties documentation.

This new architecture generates a model of the configuration and we can then output this model in various formats (the Asciidoc output you know but also files for IDEs to consume…​).

You might have to adjust your extension build file - but the changes are very minor and are documented in the migration guide.

If you encounter any issue with this new extension annotation processor, please open an issue in our tracker.

Building Quarkus itself (not your Quarkus apps) now requires Maven 3.9.6. Maven 3.9.9 is highly recommended as it contains some memory usage improvements targeting our specific use case.

Mvnd 1.0.2 is also supported.

As for your Quarkus apps, you can still build them with Maven 3.8.6+.

In Quarkus 3.13, we introduced WithTestResource to replace QuarkusTestResource, which we deprecated.

The only difference between the two was that the test resources registered with WithTestResource were restricted to the annotated class by default (whereas you had to set it explicitly for @QuarkusTestResource). This new default behavior actually caused several important issues and we decided we needed some time to make it work better.

While it is only the default value that is causing issues (you will get the same problem if you isolate all your test resources with QuarkusTestResource), a default value is important because it conveys the message that it is what we recommend. And in this case, having all your test resources isolated by default would make your tests unnecessarily slow and could consume a lot of memory.

In 3.14, WithTestResource is still around but we undeprecated QuarkusTestResource and we recommend to use QuarkusTestResource for now. If you already migrated to WithTestResource, you don’t have to revert this change, it will continue to work.

A big thank you to the Quarkus users who reported this issue with amazing reproducers, it really helped a lot.