JIRA: https://issues.redhat.com/browse/QUARKUS-2736
PR: quarkusio/quarkus#30856 (mainly)
Jakarta EE 10 has been integrated with the Quarkus main branch since the Quarkus 3.0.0.Alpha4.
The most visible change is renaming of the packages from javax to jakarta, but
Jakarta EE 10 comes with new features added to the specifications, and their implementations.
The Quarkus codebase has been adjusted, mainly Quarkus ArC, RESTEasy Classic and RESTEasy Reactive.
There is a straightforward way to migrate simple Maven projects using a JBang script.
For most things, migration to Jakarta EE 10 doesn't cause any issues, however Quarkus experienced some issues due to dependencies
that didn't migrate to Jakarta yet. For example REST Assured only worked with Jackson,
not with JSON-B, as there were no version of the REST Assured supporting the Jakarta packages.
Probably the most significant breaking change is migrating to the Jakarta Persistence Provider - Hibernate 6.2. Quarkus is still going to target Jakarta EE 9 in certain areas, Angus Jakarta Mail is an excellent example. It is important to keep in mind that QUARKUS-2736 is about migrating Java EE APIs already implemented by Quarkus to the Jakarta, not making Quarkus fully compliant with the Jakarta EE 10 specification. However, there is ongoing effort to draw nearer specification in certain areas, such as CDI Lite compliance (CDI 4.0). Quarkus deliberately fails to meet these specification requirements, that doesn't go well with Quarkus principles and concept. For example, Quarkus RESTEasy implementation choose to disable default exception mappers as Vert.X error handling provides greater capabilities.
Tests should verify:
- there is no regressing caused by the migration
- compliance with specification in areas that Quarkus integrations decided to meet, for example:
- Hibernate 6.2:
- defaults of the Jakarta Persistence
@SequenceGeneratorannotation are respected; previously implicit sequences, like thehibernate_sequencedid not
- defaults of the Jakarta Persistence
- RESTEasy Reactive support of the JAX-RS 3.1.0:
- Jakarta API changes in
jakarta.ws.rs.ext.RuntimeDelegateadded new methodscreateConfigurationBuilder,bootstrap,createEntityPartBuilderthat Quarkus decided to not support for now. We need to consider implications and confirm there is no significant impact on customers.
- Jakarta API changes in
- elder JAX-RS specification versions worked with concept of unmapped exceptions
(exceptions without default mapper), however now, there is
always at least one mapper
for each exception. On the other hand, MicroProfile requires unmapped exceptions to be counted as failed metrics.
We should evaluate and test impacts of this change.
In order to verify related failures (e.g. 1, 2), we should check:
- default RESTEasy exception mappers are disabled
and error is handled by
QuarkusErrorHandleror any Vert.X error handler with higher priority - SmallRye Health metrics for unmapped RESTEasy exceptions (responses with HTTP status 500)
- default RESTEasy exception mappers are disabled
and error is handled by
jakarta.websocket.ClientEndpointConfigaddedgetSSLContext, with which our BearerTokenClientEndpointConfigurator deals simply by returningnull. We should confirm upstream discussion that this method is unlikely to be used- determine coverage on Arc compliance with CDI Lite specification:
- CDI 4.0.1 introduces some new methods and classes, and we make sure ArC changes are backwards compatible or documented
- Using @Typed with illegal values should throw an exception
- Class based bean should not be able to retain wildcard as its bean type
- filed injection points with
@Namedwithout value should use@Named(fieldName)as the qualifier and other various compatibility fixes - and others: 1, 2, 3, 4, 5, 6, 7
- migration to Jakarta Authorization API 2.1.0 and Authentication API 3.0.0 seen implemented changes in Elytron Security backwards compatibility needs to be verified
- Hibernate 6.2:
- we have or add coverage for new features based on specification:
- Jakarta REST Services 3.1 added support for SameSite cookies
- Leverage RESTEasy Classic CDI and use @Inject instead of the deprecated @Context in RESTEasy Classic
- several MP TCK failures are expected and comes from temporary incompatibility with Jakarta EE 9 and 10, or are early resolved to avoid impact on customers
- we have necessary coverage on MicroProfile 6.0 migration that is based on Jakarta EE 10 Core Profile, to make sure there is no transient impact
- ensure good user experience and simplicity of migration to Hibernate ORM 6.2:
- add coverage for configuration property to work with database schemas generated for Hibernate ORM 5.6 as portion of these changes is related to Jakarta specification
- add coverage for
quarkus.datasource.db-versionconfiguration property - Hibernate ORM is lenient on configuration properties prefixed with
javax.persistence, however all features are not guaranteed to work withjavax, therefore we should encourage in upstream issue to log warning or fail. This way, users are going to be warned early.
- our test suites uses terminology compliant to the specification, for example:
- replace
JPAwithJakarta Persistence - replace
JAX-RSwithJakarta REST implementationorJakarta REST
- replace
Naming migration of packages and imports from javax to jakarta has already been done, there was no
regression caused by the migration, however we had to disable temporarily several tests using Quarkiverse extensions that don't have
Jakarta version yet. Such examples are Quarkus Artemis, Kogito, Quarkus Pact and Quarkus Camel. Similarly, we disabled
tests using external applications like Quarkus Quickstarts, Quarkus TODO, Quarkus Workshop etc. Enabling this test will
sufficiently prove there is no regression.
ArC changes are verified by newly enabled ArC TCK tests that are run as part of the upstream CI.
Our tests that use Hibernate 6.2 all required changes regarding sequence generation, dialects and some also needed schema migration changes. Our Quarkus Jdk specifics Test Suite cover changes in Hibernate Query Language semantics not related to Jakarta as proved by required changes. It's safe to say Quarkus Test Suite covers major Hibernate 6.2 breaking changes related to Jakarta EE 10 migration.
Default exception mappers introduced by RESTEasy Classic are covered upstream as the mappers were actually disabled in reaction to failing tests.
Elytron Security migration is sufficiently covered by Quarkus QE Test Suite, Quarkus Quickstarts run as part of upstream CI and upstream integration modules.
Quarkus Test Suite should cover newly introduced configuration properties that enforces legacy behavior and provides smooth migration.
The SameSite cookies added by Jakarta REST Services 3.1 will require one unit test with multiple HTTP requests.
Possibility to use @Inject introduced RESTEasy Classic CDI will be done by migration part of injections done with @Context.
For example, we will replace annotation on the injection point of the UriInfo.
All test suites should be refactored to use new names (Jakarta Persistence, Jakarta REST).
RESTEasy Reactive changes regarding jakarta.ws.rs.ext.RuntimeDelegate additions should be inspected manually
as they are exclusively dummy methods that throw UnsupportedOperationException and are only used in rare scenarios.
We need to assess possible use cases for getSSLContext of the BearerTokenClientEndpointConfigurator just to be sure
that it is safe to return null and do nothing.
- No additional requirements for resources in lab
- Required additional time for the test execution should be below 4 minutes as we expect but a small code additions
- No measurable additional requirements for a Native image scenario
Following actions were taken to ensure familiarity:
- Ensure documentation provides clear explanation on configuration options
- Ensure good user experience and simplicity of use
- Tester: Michal Vavřík [email protected]