On Tue, May 7, 2019 at 10:31 AM Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 07/05/2019 à 09:05, Rémy Maucherat a écrit : > > > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > > APIs in Tomcat 9 can remain javax.* and users with "old" applications > will > > still have an up to date fully compatible container for them. > > +1 > > > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > would > > provide a container for users who want to move to the new "incompatible" > > Jakarta specifications. > > +1 for deferring the package changes to Tomcat 10. > > The actual impact isn't clear though, the specifications may evolve in a > way that maintains a form of backward compatibility as outlined by Mark > Struberg (for example jakarta.* classes the extending javax.* ones). > It's a bit early to know how this could be handled in Tomcat 10. > > Once we know how the specs will evolve, I suggest releasing a prototype > as soon as possible so everyone can start experimenting with the new > namespace. The return of Jakarta Tomcat ;) > > I wonder if the specifications could be slightly refactored in the > process to erase some mistakes, for example renaming > ServletRequest.getContentLengthLong() to getContentLength(). The package > change could be a great opportunity to tidy up the APIs. > That could be good. So we'll see. > > > > This way, there's an appropriate container for everyone. Mark Struberg > > proposed more elaborate strategies using classloader tricks on the ASF > > members list, but I'm not sure this is even needed for Tomcat. > > Would such a classloader work with a native application using GraalVM ? > If not I guess we'll rather see build time tools doing the bytecode > processing than runtime tools. In this case the actual conversion would > indeed be out of scope for Tomcat. > It is unlikely classloader tricks are Graal compatible. You are right this can be a real issue in the future. > > > > Comments ? > > Not really happy to waste so much time for a silly trademark policy... > Let's hope Oracle's lawyers don't impose the same mess to OpenJDK someday. > +1 Rémy
