Jakarta EE and Java SE updates for WildFly server

[Charlie Gordon]

Hi, team!
I've got puzzled trying to understand relations between Jakarta EE, Java SE (JDK) and application server (WiildFly).
Now I have configuration which consists from WildFly 20, Oracle JDK 8 (1.8.202)
I have questions, I can't find answers to:

1. Can I update my project JDK to OpenJDK 11 (Open JDK based on Java SE specification, not on Java EE)?
2. Does WildFly 20 include all Jakarta EE specifications (so I don't need to install/upgrade it separately)? It means, that I can update JDK of my project without affecting WildFly, if WildFly supports this version of JDK.
   

Those questions are basic, but I want to clearly understand differencies and connections between WildFly, Java (Jakarta) EE and JDK. And ways how to use them together.

Best regards,
Charlie

[Brian Stansberry]

If you are running an application on WildFly 20 on SE 8, the functionality WildFly provides to your application should work fine on SE 11. It's possible some aspect of your own application's code would need some change due to the move, but that shouldn't be because of WildFly; it would be from some direct SE usage from your app.

WildFly 20 doesn't include *all* Jakarta EE specifications even on SE 8; i.e. we don't support some of the optional ones like JAX-RPC. But there is no difference in terms of what EE spec implementations we provide between SE 8 and SE 11.

However, if you are running WildFly on SE 11, formally you are not running a Jakarta EE 8 compatible implementation. This is because for a server to be a compatible EE implementation on a particular SE version it must pass the Jakarta EE Platform TCK on that SE version, and it is not possible for *any* server to do so on SE 11. This is because the EE 8 TCK was designed to run on SE 8 and has tests that don't work properly or cannot pass on other releases. Particularly tests that expose the EE API method signatures that the server exposes to applications (known as 'signature tests'). In the SE 8 TCK those tests not only inspect the APIs directly part of EE, but also those coming from SE that are incorporated in the EE APIs (e.g. say an EE API method takes java.util.Map as a parameter.) If those SE API differ from what the test expects, even if it is a purely compatible change (say a new method added to Map in SE 11), then the test will fail.

That said, experience has shown that EE 8 workloads run fine on WildFly on SE 11. We have supported SE 11 for many years.

Best regards,

Brian