Details

    • Task
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • API
    • 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

          Activity

            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

            cziegeler Carsten Ziegeler added a comment - 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
            olli Oliver Lietz added a comment -

            cziegeler, rombert, Following up on discussion in SLING-10031, should we prepare an API cleanup/improvement and roll it out once we switch to Jakarta?

            olli Oliver Lietz added a comment - cziegeler , rombert , Following up on discussion in  SLING-10031 , should we prepare an API cleanup/improvement and roll it out once we switch to Jakarta?
            olli Oliver Lietz added a comment - - edited

            cziegeler, That's the magic I was hoping for.

            olli Oliver Lietz added a comment - - edited cziegeler , That's the magic I was hoping for.
            kwin Konrad Windszus added a comment - Also Apache Tomcat provides a migration tool: https://tomcat.apache.org/download-migration.cgi  (compare with  https://lists.apache.org/thread.html/r31552357788a1671a7eda4d47f57ca1d30964e4150487267f689fdad%40%3Cdev.sling.apache.org%3E )
            enorman Eric Norman added a comment -

            Requires an update to the org.apache.felix.http.jetty bundle.

            Jetty 11.x is the release that switched to the JakartaEE namespaces, but o.a.f.http.jetty is still using the 9.x release of jetty.

            enorman Eric Norman added a comment - Requires an update to the org.apache.felix.http.jetty bundle. Jetty 11.x is the release that switched to the JakartaEE namespaces, but o.a.f.http.jetty is still using the 9.x release of jetty.

            I think cziegeler has been doing a lot of work on the Felix side for the jakarta.servlet migration. What is not clear to me is whether we can support javax.servlet and jakarta.servlet at the same time. Otherwise it's going to be a very hard sell for our users.

            rombert Robert Munteanu added a comment - I think cziegeler has been doing a lot of work on the Felix side for the jakarta.servlet migration. What is not clear to me is whether we can support javax.servlet and jakarta.servlet at the same time. Otherwise it's going to be a very hard sell for our users.

            There are many details on this - we also should separate between updating the Servlet api and any other api - the servlet API is special as that is the one we are using in our APIs. Every other API is most likely less complicated.
            Now, when it comes to the servlet API, Apache Felix Http Jetty 5.x is based on Jetty 11 and it supports jakarta servlet 5 and javax servlet 3. So that version is one way to start support Jakarta Servlet API.
            But as we are using the javax servlet api in our Sling API, it is way more difficult. We can't simply make a major version change for all Sling API as this would break all current users. The Apache Felix Webconsole had a similar problem. There we established a new API using Jakarta servlet next to the existing one. The latest webconsole supports both APIs. But again, for Sling this would have a way larger impact.

            cziegeler Carsten Ziegeler added a comment - There are many details on this - we also should separate between updating the Servlet api and any other api - the servlet API is special as that is the one we are using in our APIs. Every other API is most likely less complicated. Now, when it comes to the servlet API, Apache Felix Http Jetty 5.x is based on Jetty 11 and it supports jakarta servlet 5 and javax servlet 3. So that version is one way to start support Jakarta Servlet API. But as we are using the javax servlet api in our Sling API, it is way more difficult. We can't simply make a major version change for all Sling API as this would break all current users. The Apache Felix Webconsole had a similar problem. There we established a new API using Jakarta servlet next to the existing one. The latest webconsole supports both APIs. But again, for Sling this would have a way larger impact.

            People

              Unassigned Unassigned
              olli Oliver Lietz
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: