WildFly 32 is released!

Ever since the introduction of Galleon several years back, a major WildFly focus has been tooling to improve our users' ability to easily provision an optimal WildFly installation, on-premise and particularly for the cloud. I’m very excited to announce Final availability of a major advance in this area — the set of provisioning tools we call WildFly Glow.

The WildFly Glow tools (a CLI application and a wildfly-maven-plugin integration) analyze your application artifact, determine what WildFly feature-packs and Galleon layers are needed to run your application, and make suggestions about other features (e.g. TLS support) that you may want to include in your optimized WildFly installation. You can take the information WildFly Glow provides and use it in your own provisioning configuration, or you can have WildFly Glow provision a server, bootable jar or Docker image for you. WildFlow Glow also provides a Maven plugin to help you automate provisioning when using Arquillian.

The WildFly Glow documentation gives you a good sense of what WildFly Glow is about. But to really help you understand WildFly Glow’s benefits, I encourage you to read or watch the various posts and videos that the WildFly community has published this year:

We’ve added a new Guides page to the wildly.org site. Each guide will show the steps to accomplish a specific, focused task, with links to guides showing any prerequisites and to guides for related tasks. This is something WildFly has long needed, and we’re very excited to see it happening! We’re now up to 10 guides in a variety of topic areas. Please have a look and give us your feedback and suggestions for other guides you’d like to see.

There a number of new individual features in WildFly 32, but before getting into the individual items I want to highlight again the capabilities introduced in WildFly 31 to introduce features at different stability levels. Features can be introduced at one of four stability levels — experimental, preview, community or default — with the ideal outcome being that we promote them in subsequent releases to higher levels. The goal here is to allow users who want to look at features in earlier stages of the development lifecycle to easily do so, without leaving users who are not interested in that in a situation where they may inadvertently use those features.

We introduced this capability in WildFly 31, and added one feature at community stability, but in WildFly 32 we’ve significantly expanded our use of the concept, and added support in our provisioning tooling for it.

I’ll talk more about feature stability levels below, but first let’s talk about the new features.

Our Galleon-based provisioning tooling has also had updates related to feature stability levels: we’ve added configuration options to allow you to control the stability level of features in your installation. This can be used to do things like:

To limit your installation level to the highest stability features, you would include the following in your maven plugin configuration:

To allow Galleon to include lower stability features in your installation’s generated configuration files, you could do something like:

The latest wildfly-maven-plugin, wildfly-jar-maven-plugin (for bootable jars) and the WildFly Glow and Galleon tools all support these stability level configuration options. I encourage you to try them out.

Standard WildFly 32 is a compatible implementation of the EE 10 Platform as well as the Web Profile and the Core Profile. WildFly is EE 10 Platform, Web Profile and Core Profile compatible when running on both Java SE 11 and Java SE 17. WildFly is also a compatible EE 10 Core Profile implementation when running on SE 21.

Evidence supporting our certification is available in the WildFly Certifications repository on GitHub:

WildFly supports numerous MicroProfile specifications. Because we no longer support MicroProfile Metrics, WildFly 32 cannot claim to be a compatible implementation of the MicroProfile 6.1 specification. However, WildFly’s MicroProfile support includes implementations of the following specifications in our "full" (e.g. standalone-full.xml) and "default" (e.g standalone.xml) configurations as well as our "microprofile" configurations (e.g. standalone-microprofile.xml):

Compatibility evidence for the above specifications that are part of MicroProfile 6.1 can be found in the WildFly Certifications repository on GitHub.

I’m pleased to be able to say that our recommendation is that you run WildFly 32 on Java SE 21, as that is the latest LTS JDK release where we have completed the full set of testing we like to do before recommending a particular SE version. WildFly 32 also is heavily tested and runs well on Java 17 and Java 11.

This recommendation to run on SE 21 is a shift from previous releases, where we recommended SE 17. This is because during the WildFly 32 development cycle we completed the qualification exercise that we go through before recommending an LTS SE release.

Our recommendation of SE 21 over earlier LTS releases is solely because as a general principle we recommend being on later LTS releases, not because of any problems with WildFly on SE 17 or SE 11.

One reason to use later SE versions is because it gets you ahead of the curve as WildFly and other projects begin to move on from supporting older SE releases.

In the WildFly 30 release announcement I indicated that WildFly 30 would likely be the last feature release to support SE 11. Obviously, that is not the case as we still support SE 11 in standard WildFly 32. However, as noted above, WildFly Preview no longer supports SE 11. We’re continuing to evaluate our plans around SE 11 support, and I’ll be sure to post here as we make decisions. I do encourage WildFly users to prepare now for any eventual change to move off of SE 11.

While we recommend using an LTS JDK release, I do believe WildFly runs well on JDK 22. By runs well, I mean the main WildFly testsuite runs with no more than a few failures in areas not expected to be commonly used. We want developers who are trying to evaluate what a newer JVM means for their applications to be able to look to WildFly as a useful development platform.

Please note that WildFly runs in classpath mode.