Re: [RT] Path to Jakarta Servlet Specification
Hi, +1 from me on moving to Jakarta Servlet, for the reasons you outlined. On Tue, 2023-10-03 at 14:08 +0200, Carsten Ziegeler wrote: > Now I totally agree that this must come with nearly zero changes > required for our users. That's why I only suggested solutions where > this > should be true. On a related topic, there are source-level solutions for migrating to jakarta.servlet, e.g. [1]. These would be complementary to the eclipse transformer, which looks like a nice fit as it has both bnd and maven plugins. Thanks, Robert [1]: https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxservlettojakartaservlet
Re: [RT] Path to Jakarta Servlet Specification
Now I totally agree that this must come with nearly zero changes required for our users. That's why I only suggested solutions where this should be true. Sling is based on servlet 2 - we are not even nicely fitting into the servlet 3 world. The java world is moving to servlet 5 and 6. Major open source frameworks have already switched to the jakarta namespace. So if we don't move, we make it very hard to integrate with the latest and greatest from other places. Similar, servlet engines supporting javax.servlet are either already or plan to go into maintenance. And the other argument is perception. The more we use from the past, the less we fit into the latest and greatest and the more outdated we are perceived. Regards Carsten On 02.10.2023 14:27, Bertrand Delacretaz wrote: Hi, On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler wrote: ..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... The move looks like a lot of work, so I think we should be able to list actual benefits before deciding to do it. Especially if there's a cost to users of the Sling APIs - the overall cost can be huge. Do people know what exactly we might miss by not moving? Are there areas where the current servlet APIs prevent Sling's progress ? ...Option 3: do nothing now and wait until this switch is actually becoming a real problem... That would be my preferred option right now, but answers to my above questions might change that. -Bertrand -- Carsten Ziegeler Adobe cziege...@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Hi, On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler wrote: > ..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... The move looks like a lot of work, so I think we should be able to list actual benefits before deciding to do it. Especially if there's a cost to users of the Sling APIs - the overall cost can be huge. Do people know what exactly we might miss by not moving? Are there areas where the current servlet APIs prevent Sling's progress ? > ...Option 3: do nothing now and wait until this switch is actually becoming > a real problem... That would be my preferred option right now, but answers to my above questions might change that. -Bertrand
Re: [RT] Path to Jakarta Servlet Specification
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 cziege...@apache.org
[RT] Path to Jakarta Servlet Specification
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 cziege...@apache.org
