Jakarta migration
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:
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:
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
- create the branch
: 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.