Does WildFly use jakarta.* api or are the javax.* apis still compatible

Question

I've updated my project from Java 11 to 17 and accordingly I had to update my WildFly version from 15 to 25 because the WAR of Java 17 is not compatible with WildFly 15. Question is, do I have to migrate from javax to jakarta because the WildFly now supports the Jakarta EE 8 after WildFly 17 release? So is it really compulsory to move to jakarta from javax or there is a workaround for this?

Apocalyptic

it should be the jakarta-ee version according to the docs: wildfly.org/news/2021/10/05/WildFly25-Final-Released The standard WildFly 25.0.0 distribution is a Jakarta EE 8 compatible implementation, compatible with both the Full Platform and the Web Profile. Evidence supporting our certification is available for the Full Platform and for the Web Profile. – Centroclinal

@Centroclinal Really sorry but I didnt get this properly. Like do I have to migrate to jakarta for wildfly 25 or I can still use the javax packages and the same in the .xml file. – Apocalyptic

Answer 1

Jakarta EE 8 (Sep 2019) stil uses the javax.* package. It's essentially exactly the same as Java EE 8 (Aug 2017), it was only the brand name that has changed. Jakarta EE 9 (Nov 2020) was the first to use the jakarta.* package. It's essentially still exactly the same as Java EE 8, but now with the brand name and package name changed. Jakarta EE 10 (Sep 2022) continues using the jakarta.* package, but is essentially the first version after Java EE 8 with actual changes and new things in the API.

Note that WildFly comes as "WildFly" and "WildFly Preview". As per the docs:

WildFly versions 17 - 26 are Jakarta EE 8.
WildFly Preview versions 22 - 26 are Jakarta EE 9.
WildFly versions 27 - 33 (and Preview versions 27 - 30) are Jakarta EE 10.
WildFly Preview versions 31 - 33 are Jakarta EE 11.

In your specific case, you apparently have a Jakarta EE 8 application and a WildFly 25 server. So as long as you have picked "WildFly 25" and thus not "WildFly Preview 25", then you're fine. A quick way to verify is to blindly deploy your javax.* targeted WAR to the server and check if it doesn't throw any NoClassDefFoundError errors on javax.* classes during runtime.

By the way, the latest WildFly version supporting Jakarta EE 8 is 26, so I strongly recommend to upgrade a step further from WildFly 25 to WildFly 26.

That said, you should really migrate to jakarta.* as next step because javax.* is clearly a dead end. Also, noted should be that this all has got completely nothing to do with Java SE 17 version. Moreover, Jakarta EE 10 is still Java SE 11 compatible.

See also:

• How to use Java EE and Jakarta EE dependencies together?
• How to handle "the import cannot be resolved" compilation errors on some javax.* imports while upgrading to Spring Boot 3 and migrating to jakarta.*?

Rishi