Hi,
I committed my first attempts into a new branch and added my notes
https://github.com/apache/sling-org-apache-sling-api/blob/jakarta-2/JAKARTA.md
In most cases, we just need to add some additional methods. And then
there are some interfaces where we need to duplicate.
I think the biggest challenge is finding good names for the new
interfaces. I think we should avoid something like V2 or Jakarta in the
names. For example I created new packages for some of the interfaces
instead. There are some left where I am not sure about a good name yet.
Happy new year!
Regards
Carsten
On 02.01.2025 09:43, Konrad Windszus wrote:
Hi Carsten,
Do you have some ballpark numbers of how many classes/interfaces are affected?
Any ideas yet for a naming scheme for those new Jakarta based interfaces?
SlingHttpServletRequestV2 or anything more verbose?
Thanks and happy new year 2025
Konrad
On 31. Dec 2024, at 11:49, Carsten Ziegeler <[email protected]> wrote:
I spent some time on this topic and I am now leaning towards solving it
differently.
Our most important requirement is that existing code runs without changes. I
think our second most important requirement is to keep maintenance of Sling
code manageable as well as not causing too much discomfort to our user base.
The current plan was to update the most important parts of Sling (API, Engine,
Auth) and replace in those bundles javax.servlet with jakarta.servlet. With
that Sling would use jakarta servlet and without any further work this would be
breaking all existing code. We came up with the idea to have some tooling that
rewrites existing bundles and replaces usage of javax.servlet with
jakarta.servlet (most likely at deployment or runtime time). With that our main
requirement should be solved.
However, this most likely means that we have to maintain two branches for all
those modules for bug fixes. It also means that we create an incompatible
change for packages where it does not really make sense. The most prominent one
is the resource package where javax.servlet is only used in single methods.
It also means it is an all or nothing approach for our users. Within a single
bundle it is only possible to either use the old API or the new one - as we use
the same package and class names. I have the feeling that this will create
issues. While replacing in source code is easy, what about testing code, 3rd
party libraries etc. All of that out of a sudden needs to work with
jakarta.servlet. We have a huge ecosystem and I am almost certain that this
will create pain here and there. Might again be solvable to some degree with
additional tooling.
The easier solution for us and our users is most likely that we provide an API
that can deal with both servlet APIs, basically duplicating interfaces where
required. This allows for a step by step updating of existing user code and
provides a much better support in your IDE (the deprecated and the new method
are visible).
I was initially against this as I thought the implementation (in Sling Engine
and scripting) will be way too complicated but weighting this pain in the
implementation against potential pain for our users, I think we have to take
the pain and deal with it. It might not be as bad as I initially thought. And
to be fair, the tooling we would need is not there today either - there are
some promising basic tools we could built upon, but still it does not come for
free.
Long story short, I heavily favor now Option 1, providing new API based on
jakarta.servlet next to the existing one.
Regards
Carsten
On 01.10.2023 15:59, Carsten Ziegeler wrote:
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?
--
Carsten Ziegeler
Adobe
[email protected]
--
Carsten Ziegeler
Adobe
[email protected]
