HI Carsten, Thanks for the details in the branch. > On 2. Jan 2025, at 11:27, Carsten Ziegeler <[email protected]> wrote: > > 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. From a consumer perspective I am very much against same name class names in different packages. Leads to lot of issues with IDEs (auto-import) and wrongly imported packages (particularly with non-recommended star imports). I am in favour of a (stable) Jakarta infix in the name like SlingJakartaHttpServletRequest. I think those are sufficiently stable/accurate for the foreseeable future. Having them in a dedicated package makes sense though for the version range imports. WDYT?
> > 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] >
