Jakarta migration

Last modified by Thomas Mortagne on 2024/12/26 09:39

 XWiki
 Design
 Active
 
 
No

Description

When Oracle donated the JavaEE project to the Eclipse foundation, they maintained the copyright to the javax.* namespace. Subsequently, future versions of JavaEE, now called JakartaEE, would be required to use a new namespace for those packages. Instead of an incremental process, the Eclipse foundation opted for a big bang approach and packages formerly under the javax.* namespace has been refactored under the new jakarta.* namespace.

The first runtime consequence is to drop support for the following application servers:

  • Jetty < 11
  • Tomcat < 10

See https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/

In terms of dependencies, this move impact a lot of standard APIs.

Minimum required APIs to move to Tomcat 10+ and Jetty 11+:

Not required for Tomcat 10+ and Jetty 11+, but done anyway:

TODO:

Dependencies

Before even considering moving, we need all our dependencies to have moved to jakarta.

Dependencies which moved: see https://jira.xwiki.org/browse/XCOMMONS-2107

Dependencies which did not move: ErrorTODO

Extensions

Given the set of standard API impacted, it's going to impact a lot of JAR (at least, but also probably extensions using Groovy a lot) extensions.

Impacted extensions: ErrorTODO

Process

The move is going to be long, so ideally we need a parallel branch on which we start working on the migration and everything it implies.

Requirement before starting this migration branch:

  • feature branch support in the Jenkins pipeline accept
  • create the branch accept : the branch is feature-deploy-jakarta on xwiki-commons, xwiki-rendering and xwiki-platform repositories

Bridges

Listing here everything we can do to lower the impact on extensions.

Inject/Named

https://jira.xwiki.org/browse/XCOMMONS-2777

It should not be too hard to support both javax.inject and jakarta.inject APIs at the same time, since it's basically just about support two sets of annotations. Same for javax.inject.Named and  jakarta.inject.Named.

Provider

https://jira.xwiki.org/browse/XCOMMONS-2797

Unfortunately, it's a little more complex for javax.inject.Provider vs jakarta.inject.Provider since it's not an annotation. One possibility is to wrap one of the other depending on which one is asked and which one is available. For example, if someone try to inject javax.inject.Provider<MyComponentRole> which was registered as jakarta.inject.Provider<MyComponentRole> the component manager could:

  • try to find javax.inject.Provider<MyComponentRole> (but cannot)
  • try to find jakarta.inject.Provider<MyComponentRole> (and succed)
  • return a wrapper implementing javax.inject.Provider and internally calling jakarta.inject.Provider#get

Servlet

https://jira.xwiki.org/browse/XCOMMONS-2962

All the entry points used in web.xml were moved to jakarta without any deprecation phase. However, all the XWiki APIs that expose javax Servlet API should keep working fine, all the calls to javax Servlet APIs being bridged to their jakarta counterparts.

Mail

Error

TODO


 

Get Connected