The 32 release introduced a significant inflection in how we are using WildFly Preview. Beginning with this release we are starting to use WildFly Preview to provide a look at what we’re doing for Jakarta EE 11 support. EE 11 is not yet GA, and standard WildFly won’t support EE 11 before the WildFly 36 release, at earliest. But there are milestone, release candidate and final releases of many EE 11 specs and implementations available, so we decided to provide those in WildFly Preview. This means for a number of EE APIs, WildFly Preview no long provides an EE 10 compatible implementation.

However, for a number of specifications that are planning changes for EE 11 we are still offering the EE 10 variant. In future releases we’ll shift those to the EE 11 variants.

The following table lists the various Jakarta technologies offered by WildFly Preview, along with information about which EE platform version the specification relates to. Note that a number of Jakarta specifications are unchanged between EE 10 and EE 11, while other EE technologies that WildFly offers are not part of EE 11. Jakarta Data is a new specification added in EE 11.

Notes:

In the 34 release, WildFly Preview began integrating support for some (but not all) of the MicroProfile 7 versions of the MicroProfile specifications, replacing the MicroProfile 6.1 variants that are included in standard WildFly. The following table illustrates the differences in MicroProfile support between standard WildFly and WildFly Preview:

The APIs that WildFly Preview exposes to deployments are the EE 10 or 11 APIs, so all the classes and interfaces are in the jakarta.* packages. But you may be able to run an existing EE 8 application on WildFly Preview.

What we’ve done is we’ve added to the server’s handling of managed deployments a bytecode and text file transformation process to convert EE 8 content into EE 9. It bytecode transforms deployment jars to alter references to EE 8 packages in the class file constant tables to change from javax.* to jakarta.*. The transformation goes beyond simple package renames; a number of other known differences between EE 8 and EE 9 are handled. We owe a great deal of thanks to the community behind the Eclipse Transformer project for their work on the underlying transformation tool.

As noted above, this handling is only applied to managed deployments. A managed deployment is one where a management client (the CLI, HAL console or the deployment scanner) presents deployment content to the server and the server makes a copy of it in its internal deployment content repository. The content that gets installed into the runtime is that internal copy. Unmanaged deployments that use EE 8 APIs will not work. We transform managed deployments when we copy the deployment content into the internal content repo. For unmanaged deployments we use the original content file(s) the user provides, and WildFly Preview won’t modify those files as we don’t regard them as being 'owned' by the server.

Note that the deployment transformation feature will not update the deployment to adapt to any API differences between Jakarta EE 9 and EE 10 or later. It only covers the javax to jakarta name changes that came with EE 9.

In the long run it’s better for users if they either convert their application source to EE 10 or 11 APIs, or use build-time tooling that the Jakarta ecosystem provides to do transformation at build time. But some applications just can’t be changed, so the server-side solution WildFly Preview provides can handle those cases.

This deployment transformation feature will be removed from WildFly Preview in a future release. However, it is likely that the WildFly developers will offer a separate Galleon feature pack that can be used to add this behavior into both standard WildFly and WildFly Preview.