EAP->wildfly migration?

[Richard Oates]

Hi,

I'm investigating for my company whether it would be feasible to move from EAP 7.4  to wildfly without any major hassles in the foreseeable future. (The main reason for switching is of course to save the licensing costs.)

The main differences seem to be:

 - no (or few?) security patches

 - major releases every few months (instead of EAP patches every 6 weeks or so).

Since we're still on Java 8 the update 26->27, which introduced Java 11, is the first major hurdle, although we could maybe get around that by initally using a Java-11 JRE but compiling to Java-8. But is it likely that another update (say next year) will suddenly introduce java 17 or 21 as a base line?

Has anybody got any other general points that should be considered or experience in making this change? Arguments for staying with EAP are also welcome ;-)

thanks

richard

[Brian Stansberry]

I think you should stick to EAP! I work for Red Hat and work on EAP (and WildFly) so I am biased but I definitely think an EAP subscription brings great value.

You can get much better customer support with EAP, as a subscription allows you to get questions answered with SLAs and access to people trained in getting to the bottom of user problems. Community support for WildFly has no SLAs and TBH the WildFly developers who answer questions are not as skilled at efficiently getting the information needed to identify a problem.

The basic difference when it comes to releases is WildFly puts out new feature releases every quarter and will produce one bug-fix release about a month after each feature release. That bug fix release generally has a fairly small set of fixes, whatever is ready at the time. We very, very rarely put out micro releases solely to address CVEs. If a bug fix is not in a micro, including CVE fixes, you need to wait for the next feature release to get it, and you need to take in and qualify that new feature release, which in many enterprises is a significantly bigger task than qualifying a bug fix release. 

Historically, EAP feature releases generally come out about annually and while I don't decide these things my guess is that won't accelerate. My understanding is any faster than annually is not popular with users, who do not want to have to deal  more frequently with qualifying new feature releases in their enterprise. In between those feature releases you get regular bug fix updates.

If you use the EAP images for OpenShift you also get automatic updates of the EAP image to incorporate any bug fix updates in the underlying OS layer.

WildFly tries not to introduce incompatible changes between feature releases, but this is really a best-efforts kind of policy, and one we will break in order to adapt to the broader enterprise Java ecosystem. We've definitely been introducing a lot of breaking changes in WildFly 25 / 26 / 27 / 28.

EAP provides much stricter compatibility guarantees between releases.

In terms of the transition from WildFly 26 to WildFly 27 or the imminent 28, the biggest change is the move from EE 8 to EE 10, with the javax->jakarta package rename that comes with it.

Regarding plans for SE 11, this is just starting to attract my focused attention, so I can't say for sure when we will move to a baseline of SE 17. I don't expect a baseline of SE 21 for some years. I think a move to a baseline of SE 17 within the next 18 months is almost certain, and within the next year is likely. The shift of the enterprise Java ecosystem away from SE 11 is starting to ramp up, and even if WildFly wanted to resist that (we don't!) it's unlikely we'd be able to as doing so would prevent us keeping up with the many projects we integrate.

Best regards,

Brian Stansberry