Your feedback on migrating applications to Jakarta EE and switch from javax.* to jakarta.* namespace ...

[smarlow]

Dear community,

An important discussion is occurring regarding planning for Eclipse Jakarta EE, for which your feedback is greatly valued.  The discussion is happening on the jakartaee-platform-dev mailing list. 

A link to the email thread is here, which you should be able to read from your HTML browser.  Please join the Jakarta-platform-dev mailing list, so you can give your feedback.

In summary, a few different proposals are mentioned, to deal with transitioning from the Java EE class namespace "javax.*", over to a new namespace "jakarta.*".  Nothing is yet cast in stone, but decisions will be made based on feedback shared on the jakarta-platform-dev mailing list, so please help out.

If you also want to share feedback here as well, that is appreciated also!

Thanks,

Scott

[rcd]

Speaking as an application developer, my preference would be for a big bang rename. Yes, this will be annoying... but so will any of the other options. At least a big bang concentrates all the annoyance into a one-time switchover and avoids creating any gotchas later on. Potentially, someone could even build a tool that developers could run against their applications to "Jakartize" them. It could go through source files and replace imports, rename ServiceLoader files, update string constants, etc. That would automate most of the work and alleviate most of the pain for application developers. I imagine this would also make things easier for the WildFly (and other app server) developers, since it would be relatively easy to perform the same conversions at runtime using bytecode enhancers. That translates to less potential for bugs in WildFly itself, which is good for everyone involved.

I'm definitely against having any kind of mixture of javax and jakarta packages within the same spec. IMO that is likely to create a lot of confusion, and probably app server bugs too. Annotations are a particular problem there since you can't subclass them, as others have pointed out when discussing this issue.

[clerum]

As an developer of an application under active development which started as a Jboss Seam 2 project and has evolved to a Java EE8 project (CDI, JPA, JSF, JMS, JAX-RS, JAX-WS running Wildfly 16. This application has 2400+ java class files and over 500 JSF pages and has been migrated from Seam 2 -> EE6 -> EE7 -> EE8.

I'm in favor of Proposal 1 (Big Bang). With modern IDEs and tooling replacing out imports is a simple process that shouldn't take more than a day on an application my size. If this was spread out over multiple releases I would imagine the time commitment to hunt down the new Jakarta implementations as they change would easily be 2x.

Furthermore I think it should happen as soon as possible. Some implementations such as Mojarra (JSF) feel severely stunted after the move to ee4j. Many issues and pull requests have had little to no activity and this appears to be due to the lack of clarity in the path forward with regards to javax. (Fix for #4500 by kalgon · Pull Request #4554 · eclipse-ee4j/mojarra · GitHub )