Details
-
Task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Java EE APIs are switching from javax to jakarta.
Jakarta Specifications: https://jakarta.ee/specifications/
Candidates
- javax.activation
- javax.servlet
- javax.mail
Discovery
- Should we have branch jakarta in each module which needs to switch?
- Should we use the breaking change (major version increase in most APIs) to clean up and improve our current API or limit it to the package switch?
Tooling
Attachments
Issue Links
- is related to
-
FELIX-6247 Jakarta servlet API support by Felix HttpService
- Resolved
-
JCR-4892 support the jakarta.servlet package name
- Patch Available
-
FELIX-6574 Update to OSGi Servlet Whiteboard specification
- Closed
- relates to
-
SLING-12497 Replace Commons FileUpload with Servlet API
- Open
-
SLING-12498 Rely on servlet container for parameter handling
- Open
1.
|
Switch to Jakarta Mail and Activation APIs | Closed | Oliver Lietz | |
2.
|
Support Jakarta Servlet APIs | Resolved | Robert Munteanu | |
3.
|
Enhance Sling API to support Jakarta Servlet | In Progress | Carsten Ziegeler | |
4.
|
Enhance Auth Core to support Jakarta Servlet API | In Progress | Carsten Ziegeler | |
5.
|
Implement Jakarta Servlet based API | In Progress | Carsten Ziegeler | |
6.
|
Implement Jakarta Servlet based Sling API | In Progress | Carsten Ziegeler | |
7.
|
Implement Jakarta Servlet based Sling API | In Progress | Carsten Ziegeler | |
8.
|
Implement Jakarta Servlet based Sling API | In Progress | Carsten Ziegeler | |
9.
|
Migrate Servlets Get to Jakarta Servlet API | In Progress | Carsten Ziegeler | |
10.
|
Add Jakarta Servlet based API to Post Servlet | In Progress | Carsten Ziegeler |
In general, we should only switch, if there is a real need.
I haven't looked in detail into it, but maybe https://github.com/eclipse/transformer can help here (for example by rewriting bundles using the old api to use the new api), avoiding branches and deploying two versions in parallel