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. > 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. > 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. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
