WildFly 18 is released!

I’m pleased to announce that the WildFly 18 Final zip is now available for download.

This has been a very busy summer for the many folks who contribute to WildFly; a lot of long hours and a lot of progress. I’m forever grateful for the chance to work on a project with such a great group of people.

So, what have we been up to?

Jakarta EE and Java EE

As I announced last month, WildFly 17.0.1 was certified as a Jakarta EE 8 compatible implementation. As you would expect, WildFly 18 is compatible as well, with both the Full Platform and the Web Profile. Evidence supporting our certification is available here for Full Platform and here for the Web Profile.

WildFly 18 is also a certified compatible implementation of Java EE 8.

Besides ensuring WildFly is a compatible Jakarta EE 8 implementation, we put a lot of effort into better alignment with the Jakarta EE API projects, which I explain further below.

MicroProfile 3

In addition to the parts of MicroProfile that are also in EE 8, WildFly provides support for five other MicroProfile standards. For WildFly 18 we have upgraded those to the spec versions included in the MicroProfile 3.0 release:

Specification Version in WildFly 18

MP Config

1.3

MP Health Check

2.0

MP Metrics

2.0

MP OpenTracing

1.3

MP Rest Client

1.3

MicroProfile will be a significant focus for the next couple of WildFly releases. For WildFly 19 we are aiming to introduce support for the three remaining required MP 3 specs that we don’t currently support: MP JWT Authentication, MP Fault Tolerance and MP Open API.

Security Enhancements

WildFly 18 brings a number of enhancements in the security area:

Enhancements to the EE Subsystems

There are a number of new features provided by various WildFly subsystems that I’ll lump into the 'EE' category:

Clustering Enhancements

As always, the folks working on clustering have been busy as well:

  • For a clustered web app the JSESSIONID can now be encoded with multiple routes, ranked in order of preference. Thus, if the primary owner of a given session is inactive (from the load balancer’s perspective), the load balancer can attempt to route the request to the next route in the list. This ensures that requests will be directed to the next best worker in the event that the primary owner is inactive, and prevents requests from "spraying" across the cluster.

  • The Infinispan subsystem now exposes management metrics for remote HotRod caches.

Management

WildFly in the Cloud

We’ve continued to make a lot of progress on the source-to-image (s2i) image for WildFly and on the WildFly Operator for Kubernetes/OpenShift. We’ll provide further details on what’s new there in the next couple of weeks when we announce new versions of those images based on the WildFly 18 server release.

Alignment with Jakarta EE API Projects

Besides ensuring we could certify as Jakarta EE 8 compatible, a lot of effort this summer went into further aligning with the Jakarta community. Specifically, WildFly incorporates a large number of component jars that provide the various EE APIs. For some EE specs WildFly directly provided jars produced by the various Java EE spec projects; for others the JBoss.org community has provided its own jars, derived from source from the Java EE spec projects. For both cases, for WildFly 18 we moved to align the source for our API jars with the source coming from the active Jakarta community.

  • For projects where we were directly shipping a jar from a Java EE 8 project, we switched to a jar from the equivalent Jakarta project. As a result the Maven groupId and artifactId of these artifacts has changed.

  • For projects where we were consuming an API jar produced by a JBoss.org community project, for all of those projects a new github repo was created, with the initial code derived from the Jakarta projects, and new releases were produced. For these APIs the Maven groupId and artifactId did not change (except for JTA, where we moved from the 1.2 version of the spec to 1.3, which affected the artifactId). The new releases have a maven version number one higher than the previous release, but this version bump solely reflects the new origin of the source code. It does not indicate major changes in the source itself.

It’s important to emphasize that the Jakarta EE 8 APIs are API identical to the Java EE 8 APIs and generally the method implementations are identical as well. So this change of the source from which we get the API jars is not expected to introduce any runtime incompatibility. This change is all about aligning the code we provide with projects that are actively maintained.

If you were compiling a deployment project against the Java EE 8 API artifacts we shipped in WildFly 17, that deployment should run fine on WildFly 18.

WildFly provides a number of maven boms for each release. These boms have been updated to use the Jakarta-based dependencies. In addition, the previous boms with maven ids org.wildfly.bom:wildfly-javaee8 and org.wildfly.bom:wildfly-javaee8-with-tools have been discontinued and new boms org.wildfly.bom:wildfly-jakartaee8 and org.wildfly.bom:wildfly-jakartaee8-with-tools have been introduced. Note that this name change does not indicate the WildFly 18 is not a Java EE 8 compatible server. We’re just aligning our names with Jakarta EE.

Within the WildFly runtime, deployments don’t concern themselves with the Maven GAV of the API jars we provide. To the extent a deployment is concerned at all about the details of how EE API classes are made visible (which would not be common), it would be interested in the names of the JBoss Modules modules that provide the spec classes. All of the existing EE API modules from WildFly 17 still exist in 18 — with the same names — and provide the equivalent APIs so there is no need for deployment authors to make any changes.

JDK 13

Our goal with WildFly is to have our releases run well for most use cases on the most recent GA JDK version available on the WildFly final release date. I’m pleased to report that this is the case with WildFly 18 and JDK 13. By run 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 the latest JVM means for their applications to be able to look to WildFly as a useful development platform.

While we do want to run well on the most recent JDK, our recommendation is that you run WildFly on the most recent long-term support release, i.e. on JDK 11 for WildFly 18. We do considerably more testing of WildFly itself on the LTS JDKs, and we make no attempt to ensure the projects producing the various libraries we integrate are testing their libraries on anything other than JDK 8 or 11.

WildFly 18 also is heavily tested and runs well on Java 8. We plan to continue to support Java 8 at least through WildFly 21, and probably beyond.

Please note that WildFly runs on Java 11 and later in classpath mode.

At this point it is uncertain whether we’ll be able to say that the release of WildFly that follows JDK 14 going GA will run well on 14. We’ll have to see how well the work for that, both in WildFly itself and in the projects we integrate, aligns with our other goals for that release.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 10 releases included with WildFly 18 are available here.

Enjoy, and as always, thank you so much for your support of WildFly!