Migration Guide 3.19

Table of Contents

• Config changes
  • Compatibility layers
  • Other changes ⚙️ ✅
  • Quarkiverse Micrometer Registry
• Hibernate ORM
  • Bean Validation integration
• Testing
  • Mockito inline strategy
• UBI 9
• OpenTelemetry
  • Breaking changes from the OpenTelemetry project
• Native mode image processing (ImageIO, AWT)
• BouncyCastle

Note	We highly recommend the use of quarkus update to update to a new version of Quarkus. Items marked below with ⚙️ ✅ are automatically handled by quarkus update.

Config changes

We migrated all the Quarkus config properties to the new @ConfigMapping based framework.

If you develop extensions and are injecting some configuration classes into your extensions, be aware that they are now interfaces and using methods instead of fields.

For some very commonly consumed config classes, we kept a compatibility layer for common properties but these compatibility layers will disappear in the future.

We encourage extension owners to move to the new config infrastructure based on @ConfigMapping. You can find a lot of examples here: https://github.com/quarkusio/quarkus/pulls?q=is%3Apr+ConfigMapping+in%3Atitle+is%3Aclosed And don’t hesitate to ping us if you have questions or need any help.

Compatibility layers

To ease the transition, the following configuration classes have been kept around (but limited to very few properties) and are deprecated:

• GlobalDevServicesConfig: use DevServicesConfig instead

• HttpConfiguration: use VertxHttpConfig instead

• HttpBuildTimeConfig: use VertxHttpBuildTimeConfig instead

Other changes ⚙️ ✅

In passing, we made a few adjustments to some properties that were annoying when using YAML:

• In Vert.x HTTP, quarkus.http.cors is deprecated and may be replaced with quarkus.http.cors.enabled

• In Logging JSON (the extension in Core), quarkus.log.*.json is deprecated and may be replaced with quarkus.log.*.json.enabled. It concerns all the following properties: quarkus.log.console.json, quarkus.log.file.json, quarkus.log.syslog.json, and quarkus.log.socket.json.

Quarkiverse Micrometer Registry

If you are using the Quarkiverse Micrometer Registry extensions, make sure you update to 3.3.0.

Hibernate ORM

Bean Validation integration

Bean Validation integration changes its default behavior and now considers validation constraints while generating DDL. To preserve the previous behaviour, use quarkus.hibernate-orm.validation.mode=callback.

quarkus.hibernate-orm.validation.enabled is deprecated. To disable the Bean Validation integration, set quarkus.hibernate-orm.validation.mode=none instead.

Testing

Mockito inline strategy

When the quarkus-junit5-mockito dependency, Mockito is now configured to used the (default) inline stategy as opposed to the subclass strategy that previously being employed.

UBI 9

Starting with Quarkus 3.19, the builder and runtime base images use UBI 9 by default, instead of UBI 8.

UBI 8 is approaching its end of support, which will raise security concerns in the future.

IMPORTANT: If you compile your native executable using an in-container (using -Dquarkus.native.container-build=true build with a UBI 9-based builder image (which is the default starting with Quarkus 3.19), you must use a UBI 9-based runtime image.

To switch back to UBI 8:

• For builder images, set -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

• For runtime image, in JVM mode, use registry.access.redhat.com/ubi8/openjdk-21-runtime:1.21 as the base image of your container.

• For runtime image, in native mode, use either registry.access.redhat.com/ubi8-minimal:8.10 if you want to use UBI minimal or quay.io/quarkus/quarkus-micro-image:2.0 for the Quarkus micro image as the base image of your container.

To update to UBI 9:

• For builder images, it will be done automatically. However, you can specify the builder image using: -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=quay.io/quarkus/ubi9-quarkus-mandrel-builder-image:jdk-21

• For runtime image, in JVM mode, use registry.access.redhat.com/ubi9/openjdk-21-runtime:1.21 as the base image of your container

• For runtime image, in native mode, use either registry.access.redhat.com/ubi9-minimal:9.5 if you want to use UBI minimal or quay.io/quarkus/ubi9-quarkus-micro-image:2.0 for the Quarkus micro image as the base image of your container.

Note: microdnf in UBI 9 requires -y flag to assume "yes" and don’t hang on Is this ok [y/N]:.

OpenTelemetry

This release uses OpenTelemetry SDK 1.44.1 and the opentelemetry-proto 1.3.2-alpha that is used in the OpenTelemetry Collector version 0.114.x or below.

Breaking changes from the OpenTelemetry project

Some database incubating values, like the ones related with Redis, were moved to a different package. There is no list of changes being maintained by OpenTelemetry for database semantic conventions because they are not stable yet. This change might require manual intervention if you use manual instrumentation.

Native mode image processing (ImageIO, AWT)

Server-side headless image processing, enabled by the AWT extension (e.g., for PDF document processing), is not supported on Linux aarch64 when using GraalVM/Mandrel JDK 24. Support is restored with GraalVM/Mandrel for JDK 25. Linux amd64 is unaffected.

BouncyCastle

This release uses BouncyCastle version 1.80. It may require projects that currently work with older BouncyCastle versions such as 1.78.1 to add the bcutil dependency to work around issues related to some of the BouncyCastle related package updates:

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcutil-jdk18on</artifactId>
</dependency>