A project that might help if we try option 2:
https://github.com/eclipse/transformer (initially written for exactly
this use case)
Regards
Carsten
On 01.10.2023 15:59, Carsten Ziegeler wrote:
Hi,
we should discuss whether and if how we want to move to the Jakarta
Servlet Specification.
For everyone this is a "quick" recap of todays landscape (in general):
- Sling is based on Servlet 2/3 which uses the javax.servlet package
namespace
- Servlet 4 is the last specification using the javax.servlet namespace
- With the move of all enterprise specifications to the Eclipse, all
specification went through package renaming. Servlet 5 is the first
version using the jakarta.servlet package namespace. It is identical to
Servlet 4 - except for the packages.
- In general, migration from Servlet 4 to Servlet 5 "just" requires all
packages to be renamed; this can be done in source or binaries - at
build time or at runtime.
- The latest specification is Servlet 6 which added minor features to
Servlet 5 *but* removed all things that were deprecated in Servlet 5.
This means if you have code using those deprecated methods, you need to
adjust your code to get to Servlet 6
- It seems that servlet engines like Jetty (which we use through Apache
Felix) require users to migrate. Jetty 9/10 support javax.servlet 3/4,
Jetty 11 only supports Jakarta Servlet 5 and Jetty 12 only support
Jakarta Servlet 6.
- OSGi Specifications: The old http service is tied to javax.servlet.
This one should not be used as it got replaced by the http whiteboard.
- OSGi Specifications: http whiteboard supports Servlet 3/4
- OSGi Specifications: servlet whiteboard supports Servlet 5 (and in
theory Servlet 6).
- OSGi Specifications: It is possible to run all of the above three
specifications in parallel
- Implementation: Apache Felix Http Jetty 5.x supports all of the above
OSGi specifications and Servlet API 2 to 5. You can mix and match old
code with new code - this allows for an easier upgrade path for consumer
as you can transitions parts of your code base one after the other.
When we are talking about Sling, things get more complicated as most of
our API uses javax.servlet as part of the API, so simply changing that
API from javax.servlet to jakarta.servlet will break everyone out there.
Basically all of our API is affected, unfortunately including all the
resource resolver related API packages!.
The Apache Felix Webconsole was in a similar situation as Sling but with
a way smaller API. Here we just created a new API next to the old one,
now allowing to run plugins using old and new API in parallel. This
support works in every servlet engine using javax.servlet - and
eventually will move to require a jakarta.servlet based engine.
So the first question for us is now, do we want to support the Jakarta
Servlet API?
It seems the Java world around us is moving to Jakarta and if we want to
benefit from upcoming new features in that world, we eventually have to
move.
There are different options to do this move:
Option 1: provide new API interfaces based on Jakarta - parallel to the
old ones with side-by-side packages (similar to the web console). Maybe
this should focus on Servlet 6 (with removed deprecated stuff), to not
have two migration steps for the users. While this is also an
opportunity to clean up our API around the Servlet API, it unfortunately
includes a complete fork of our API - and the implementation to support
old and new one will be pretty complex.
Option 2: Update the existing API directly to Servlet 5/6. This breaks
all code out there and forces it to migrate. This is only an option if
we could provide tooling (byte code rewriting?) that either at assembly
or runtime rewrites usage of the old packages to the new packages. This
approach would not allow us to clean up the API. That would need to be
handled separately.
Option 3: do nothing now and wait until this switch is actually becoming
a real problem.
Giving the complexity of this problem, option 3 is maybe not the best
choice. Option 1 is very tempting, but I fear the complexity and risk
involved. I did this work for the web console and it was already quite
challenging there. If Option 2 would work, this could be a nice way out.
Thoughts? Maybe there are better options?
Regards
Carsten
--
Carsten Ziegeler
Adobe
[email protected]
