WildFly 17 is released!

I’m pleased to announce that WildFly 17 Final is now available for download.

A lot of effort in this last quarter has gone into using WildFly in cloud environments, which I’ll expand on more below, but first I wanted to touch on improvements we’ve made in the main WildFly server.

Clustering Improvements

Messaging Improvements

  • We’ve added support for messaging clusters behind http load balancers by disabling automatic topology updates on clients. (This allows the client to continue to address the load balancer rather than trying to communicate with the servers behind the load balancer.)

  • The timeout the embedded messaging broker uses for opening journal files is now configurable.

  • Configurability of connections to remote AMQ brokers has been enhanced.

Other Notable Items

WildFly in the Cloud

As we continue with our quarterly delivery model, a major focus continues to be on making WildFly as easy and productive as possible to use on the cloud, particularly on Kubernetes and OpenShift. Quite a lot has happened this past quarter:

First, there’s now a launcher allowing you to use WildFly as a backend runtime at https://launch.openshift.io !

Second, I’m very pleased to announce the first release of our WildFly Operator for Kubernetes/OpenShift. It’s available at operatorhub.io — try it out! Or even better lend a hand at https://github.com/wildfly/wildfly-operator . This is a key step in making it easier to manage WildFly-based applications in the cloud, with more to come.

Finally, the Galleon-driven cloud image prototype work that Jean-Francois Denise described in March is making very good progress. It’s leading to the next generation of source-to-image (s2i) for WildFly. Later this week Jean-Francois will be uploading WildFly 17-based images to quay.io. In the meantime, I encourage you to learn more about these efforts or even have a go at building the images yourself.

For those of you who have previously used the OpenShift s2i image for WildFly, please note that going forward development will be happening at the new source repo under the wildfly GitHub organization.

JDK 12 and 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 17 and JDK 12. By run well, I mean our main 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 their development platform. It may not always be possible to attain this goal, but it’s one we take seriously.

Although JDK 13 is still in the EA stages, Richard Opalka continues to informally test WildFly against the EA releases as they come out and he reports that it is working well.

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 17. We do considerably more testing on the LTS JDKs.

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

Please note that WildFly runs on Java 11, 12 and 13 in classpath mode.

Jira Release Notes

The full list of issues resolved is available here. Issues resolved in the WildFly Core 9 releases included with WildFly 17 are available here and here.

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