Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

javax to jakarta migration

100 views
Skip to first unread message

Leon Morley

unread,
Apr 23, 2025, 11:39:52 AMApr 23
to WildFly
Is there a definitive list of javax packages that are required to be migrated to jakarta? I have found some modules under the javax folder in the Wildfly distribution that seem to be automagically converted over to jakarta if they are deployed. Is this everything? I have found this, but not sure that this is the full list:  platform/namespace/unaffected-packages.adoc at main · jakartaee/platform · GitHub. Just wondering because I am looking at rather a large scale migration and want to be able to tell if particular jars require migrating based on whether they contain specific javax imports. It is not really an option to deploy to check because this is a discovery phase of the project and we have no real environment to deploy to, so I am just scanning jars currently to determine if they are candidates for migration.

Stephen Sill II

unread,
Apr 23, 2025, 12:02:40 PMApr 23
to WildFly
oh man, that's a process!   Nowhere near as bad as the java 8->11 switch but... still not fun.   If you deploy to kubernetes ,  minikube is a great way to test your deployment without consequence.

Emmanuel Hugonnet

unread,
Apr 23, 2025, 12:27:23 PMApr 23
to wil...@googlegroups.com
You might want to take a look at
https://github.com/eclipse-transformer/transformer
I'm not sure if there is a dry run just to get the report you are loooking for.
Cheers,
Emmanuel


Le 23/04/2025 à 18:02, Stephen Sill II a écrit :
> oh man, that's a process!   Nowhere near as bad as the java 8->11 switch but... still not fun.   If you deploy to kubernetes ,  minikube
> is a great way to test your deployment without consequence.
>
> On Wednesday, April 23, 2025 at 9:39:52 AM UTC-6 Leon Morley wrote:
>
> Is there a definitive list of javax packages that are required to be migrated to jakarta? I have found some modules under the javax
> folder in the Wildfly distribution that seem to be automagically converted over to jakarta if they are deployed. Is this everything? I
> have found this, but not sure that this is the full list: platform/namespace/unaffected-packages.adoc at main · jakartaee/platform ·
> GitHub <https://github.com/jakartaee/platform/blob/main/namespace/unaffected-packages.adoc>. Just wondering because I am looking at
> rather a large scale migration and want to be able to tell if particular jars require migrating based on whether they contain specific
> javax imports. It is not really an option to deploy to check because this is a discovery phase of the project and we have no real
> environment to deploy to, so I am just scanning jars currently to determine if they are candidates for migration.
>
> --
> 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 visit https://groups.google.com/d/msgid/wildfly/c52edaf1-9e8f-448d-9871-f8f4199f0725n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/c52edaf1-9e8f-448d-9871-f8f4199f0725n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Emond Papegaaij

unread,
Apr 23, 2025, 2:07:53 PMApr 23
to wil...@googlegroups.com
Hi,

We've developed a maven enforcer plugin for exactly this: https://github.com/topicusonderwijs/enforcer-ban-class-usage
Unfortunately, it's built on top of our proprietary parent pom, but it shouldn't be too hard to get that out for a small project like this.

The plugin will fail the build if it detects usage of any banned classes, anywhere in the code. You can configure it with the javax API classes. You can also exclude certain artifacts, for example if a library provides an API for both the old javax and the new jakarta namespaces.

Best regards,
Emond

Op wo 23 apr 2025 om 18:27 schreef 'Emmanuel Hugonnet' via WildFly <wil...@googlegroups.com>:
To view this discussion visit https://groups.google.com/d/msgid/wildfly/deb01471-b2a8-43e5-93fb-fc6b811c5ac9%40redhat.com.

Brian Stansberry

unread,
Apr 23, 2025, 9:51:31 PMApr 23
to WildFly
The Eclipse Transformer code base includes a lot properties files that drive the various kinds of transformation it performs. The ones for the general EE 8 -> 9 transformation are here:


This one lists the Java packages it renames:


I recommend using the tool itself though, not just seeing what's in these files. :)

Leon Morley

unread,
Apr 24, 2025, 4:26:51 AMApr 24
to WildFly
Thankyou all for your prompt replies. A lot of really helpful information. I was looking at this file as suggested by Brian Stansberry and I am a little confused (it doesn't take much). So, I can see that line 158 here: renames javax.xml.ws to jakarta.xml.ws. Does this mean that anything under javax.xml.ws should be converted to jakarta.xml.ws? If so, why bother listing the packages above such as here where it renames javax.xml.ws.wsaddressing. Any ideas?

Scott Marlow

unread,
Apr 24, 2025, 8:30:20 AMApr 24
to Leon Morley, WildFly
On Thu, Apr 24, 2025 at 4:27 AM 'Leon Morley' via WildFly <wil...@googlegroups.com> wrote:
Thankyou all for your prompt replies. A lot of really helpful information. I was looking at this file as suggested by Brian Stansberry and I am a little confused (it doesn't take much). So, I can see that line 158 here: renames javax.xml.ws to jakarta.xml.ws. Does this mean that anything under javax.xml.ws should be converted to jakarta.xml.ws? If so, why bother listing the packages above such as here where it renames javax.xml.ws.wsaddressing. Any ideas?

https://jakarta.ee/specifications/ has each of the Jakarta EE specification document links and related SPEC API javadoc links as well.  For example, see https://jakarta.ee/specifications/xml-web-services/4.0/apidocs/jakarta.xml.ws/module-summary.html which has:

"
Jakarta XML Web Services API.

References in this document to JAX-WS refer to the Jakarta XML Web Services unless otherwise noted.
References in this document to SAAJ refer to the Jakarta SOAP with Attachments unless otherwise noted.
References in this document to JAXB refer to the Jakarta XML Binding unless otherwise noted.
References in this document to JWS refer to the Jakarta Web Services Metadata unless otherwise noted.

"

Having the ^ reference pages can be helpful in understand exactly which jakarta.* SPEC API classes are in each Jakarta EE SPEC.

Hope this helps,
Scott
 

Stephen Sill II

unread,
Apr 24, 2025, 8:43:19 AMApr 24
to WildFly
I did this upgrade quite sometime ago for the few apps I maintain, as well as going to java 21.   I didn't realize there was a tool lol.    In most cases it's as simple as changing javax.whatever to jakarta.whatever in your source and then updating your pom.xml files with the dependencies that give you the jakarta.whatever classes and not the javax. ones.

Just as an example for deps
            <dependency>
                <groupId>jakarta.ws.rs</groupId>
                <artifactId>jakarta.ws.rs-api</artifactId>
                <version>3.1.0</version>
                <scope>provided</scope>
            </dependency>

In a lot of cases it was updating the version of deps and plugins and in maven especially for the later java version support.

Good luck!

Stephen Sill II

unread,
Apr 24, 2025, 8:45:12 AMApr 24
to WildFly
yes, what scott posted above.    The process can certainly be done manually like I did it.  I generally prefer the manual approach so I fully understand what changes are happening.

Leon Morley

unread,
Apr 24, 2025, 8:54:05 AMApr 24
to WildFly
"pom files". Ha ha, I wish. The client are still using Ant and I need also to migrate those Ant builds to Gradle as part of the same project.

Stephen Sill II

unread,
Apr 24, 2025, 9:04:12 AMApr 24
to WildFly
ant.... that's not something I've thought of in at least 15 years lol
I've not yet jumped on the gradle band-wagon yet.  But I tend to be very proactive when it comes ot updates of things like the java version,JEE/jakarta etc so I always start looking at them early so it's not a huge panic.  It still amazes me that people are still holding on to java 8 lol.   I still have memories of converting from 8->11 and that was no fun.  but 11->17 and then 17-21 wasn't a big deal.

My guess is you can make bank going around to these folks that have stayed on the old stuff and waited to move to newer versions.  Been doing java version upgrades since 1.4 haha  Been doing jboss(wildfly) upgrades since before it was called wildfly haha, jboss AS 7 lol

Good luck to you sir

Brian Stansberry

unread,
Apr 24, 2025, 4:23:12 PMApr 24
to Leon Morley, WildFly
On Thu, Apr 24, 2025 at 3:27 AM 'Leon Morley' via WildFly <wil...@googlegroups.com> wrote:
Thankyou all for your prompt replies. A lot of really helpful information. I was looking at this file as suggested by Brian Stansberry and I am a little confused (it doesn't take much). So, I can see that line 158 here: renames javax.xml.ws to jakarta.xml.ws. Does this mean that anything under javax.xml.ws should be converted to jakarta.xml.ws? If so, why bother listing the packages above such as here where it renames javax.xml.ws.wsaddressing. Any ideas?

The way the tool works, it doesn't assume sub-packages need to be updated just because a parent package is listed. So you should see all the packages explicitly listed in its config files.

The tool having that design results in requiring a more verbose config file, but it allows it to handle some corner cases. For example in the file you'll see the entry 'javax.annotation=jakarta.annotation' but in the https://github.com/jakartaee/platform/blob/main/namespace/unaffected-packages.adoc document from your original post you'll see some javax.annotation subpackages that are part of Java SE and are not to be renamed to jakarta.

To view this discussion visit https://groups.google.com/d/msgid/wildfly/b9b9b164-9b4e-4f41-aac6-0991bf2a9222n%40googlegroups.com.


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His

James Perkins

unread,
Apr 30, 2025, 10:45:19 AMApr 30
to WildFly
A bit of a late reply. I haven't used this specific recipe, but I've used OpenRewrite for some other things and been quite happy with it https://docs.openrewrite.org/recipes/java/migrate/jakarta/jakartaee10.

Brian Stansberry

unread,
May 1, 2025, 9:25:10 AMMay 1
to James Perkins, WildFly
Thanks for the reminder, James, and my apologies, Leon, for not posting this before:

https://windup.github.io/blog/javax-jakarta-openrewrite-automigrate/

To view this discussion visit https://groups.google.com/d/msgid/wildfly/1c4bade2-76bd-419c-9b6c-1e8f7e38b30fn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages