Quarkus 1.6 released - AppCDS, Google Cloud Functions, GraalVM 20.1.0 and more...

Quarkus 1.6 introduces the ability to automatically generate AppCDS as part of the build process.

Essentially if you are using Java 11+, by configuring quarkus.package.create-appcds=true (yes, it’s that simple!) Quarkus will create an AppCDS file that you can then leverage to improve the startup time of the application in JVM mode. The AppCDS file is named app-cds.jsa and is generated in the same directory as the application jar (all types of Quarkus jars are supported).

To make use of it, just run java -jar -XX:SharedArchiveFile=app-cds.jsa myapp.jar from the directory where both the jar and AppCDS file are present (this doesn’t have to necessarily be the original build directory, but the files do need to be in the same directory and the java process must be run from it). Note that this directory requirement isn’t a Quarkus specific limitation, but a JVM requirement stating that the classpaths must be the same when building the AppCDS file and running the application with it. Finally, make sure to use to same JVM version when building and running the application (again this is a JVM limitation).

In the coming days we will have a lot more details to share via a dedicated blog post.

Although this feature is experimental and still needs to be integrated properly with the container-image generation extensions, it nevertheless is fully functional.

Quarkus 1.6 introduces some useful endpoints have an overview of your CDI context with /quarkus/arc/beans and /quarkus/arc/observers.

They are described at length in the CDI reference guide.

It used to be unlimited by default, we now limit it to 10 MB. Of course, you can still configure it via quarkus.http.limits.max-body-size.

Quarkus now support serverless on all the major cloud providers with the addition of the support for Google Cloud Functions.

Eager to discover more about it, we have two new guides for you either if you want to develop a simple function or use HTTP.

We now have reactive SQL clients for MySQL/MariaDB, PostgreSQL and IBM Db2.

An Apache Cassandra client has joined the Quarkus Platform.

Learn more about how to use Cassandra in your Quarkus applications in the dedicated guide.

If you are using webjars in your application, we now provide an extension allowing you to drop the version from the webjar path.

More information in our documentation.

Our Spring compatibility layer is becoming more and more comprehensive with the addition of the support for Spring’s @Scheduled annotation.

What we support and the current limitations are all described in this new guide.

Like to trace things? Love GraphQL?

We got you covered as OpenTracing is now enabled in the SmallRye GraphQL extension as soon as the OpenTracing extension is around.

The OptaPlanner extension has been extracted from the Quarkus core repository to the OptaPlanner repository.

In passing, the artifact ids have changed so, if you are using the OptaPlanner extensions in your project, please move to the new ones:

The artifacts are part of the Quarkus Platform so:

We upgraded to GraalVM 20.1.0. While older versions might still work, we recommend an upgrade to this version.

The way trust stores are handled by native images has radically changed with GraalVM 19.3.

Our documentation was outdated and not very helpful in this regard, it has been updated.

Quarkus startup time and runtime performances are always improving and the main reason for that is that we get useful feedback from our community. (Well, and we do benchmarks too.)

When you encounter a performance issue with Quarkus, we often ask for more details and you might not be accustomed with the various tools that would give us useful insights.

Profiling startup or runtime slowness in user applications is made easy with our new TROUBLESHOOTING.md.

This change will concern you only if you are an extension developer: Quarkus now validates that the deployment and runtime dependencies are consistent in an extension.

If Quarkus warns you about it, check that each runtime dependency has the corresponding deployment artifact in the deployment pom.