WildFly 26.1.3 and Java 21 Compatibility

[Greg Parmiter]

Hi folks, it appears that WildFly 30.0.1 has been tested and certified against Java 21, but due to project constraints, we're looking to remain on WildFly 26.1.3 and upgrade the Java runtime to version 21. 

Has WildFly 26.1.3 been tested in a Java 21 runtime environment? If so, can anyone share those results?

Thank you!

[Brian Stansberry]

Hi Greg,

Sorry; the WildFly project has never tested 26.1.3 or the 26.x branch it came from using SE 21.

Best regards,

Brian

[Greg Parmiter]

Thanks Brian. A couple of follow-up questions-

I realize this question is broad- traditionally, do you see regressions when running under later versions of Java?

When will Java 21 be fully tested and supported? (It looks like even in WildFly 31.0.1, Java 21 testing was only done on Core)

[Everly, David W]

Not speaking for Wildfly, but...

https://en.wikipedia.org/wiki/Jakarta_EE

...indicates that Jakarta EE 10 supports Java SE 11 and 17.  Jakarta EE 11 (not yet finished) is slated to support Java SE 21.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/3644f0ec-4bf2-49aa-9462-e645f27c1dfan%40googlegroups.com.

[Brian Stansberry]

Hi Greg,

Sorry for the slow reply.

Generally speaking, we don't see a lot of problems with our own production code when moving between SE versions. This is partly because Richard Opalka does a good job of keeping on top of upcoming SE versions and sends up fixes. In general these are not big things though.  A big exception was in the security area during the transition between SE 11 and SE 17, when SE removed a number of packages that our legacy Picketbox security layer used, requiring us to remove support for that (long deprecated) layer.

Note though the WildFly incorporates hundreds of components and if some of those components had to do significant work to be compatible with a newer SE we might not be aware of it.

Regarding SE 21 support, for a more thorough answer please have a look at https://www.wildfly.org/assets/data/wmc_whats_new_and_roadmap.pdf, starting at slide 19. Our hope was we'd be able to say SE 21 is our recommended version for the upcoming WildFly 32, and it's looking good that we'll be able to do that.

However, that doesn't mean WildFly 32 will be able to certify as EE 10 compatible when running on SE 21. Certifying as compatible means passing all tests, and if a test cannot be passed on SE 21 because of a problem in the test itself, then we can't certify. But that's a test problem, not a WildFly problem. We currently see several dozen failures out of over 70,000 tests when running on SE 21, none of which are due to problems in WildFly.

As David Everly pointed out, EE 11 specifically calls out support for SE 21. However, an important improvement that Jakarta's done in recent EE releases (I believe since 9.1) is introducing the concept that it should be possible to certify on SE releases that come out after the EE release. The goal is to have the specification and the TCK not limit implementations like WildFly to SE versions that existed when EE was released. So, when WildFly or other communities find problems like our 40+ test failures, we can and do file issues with the relevant Jakarta spec communities to try and get tests corrected so they work on SE 21, or to get them excluded from the TCK. (Jakarta has formal processes for this kind of thing.) There are issues like this in progress, and if they get resolved before WildFly moves on to EE 11 support then we'll aim to certify as EE 10 compatible on SE 21.

Best regards,

Brian

--

You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/3644f0ec-4bf2-49aa-9462-e645f27c1dfan%40googlegroups.com.

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

WildFly Project Lead

He/Him/His

[Greg Parmiter]

Thanks for clarifying, Brian. This will be helpful as we move forward.