i think the whole point was that they had to break with the "javax" naming because oracle doesn't allow that outside it stuff.
not sure if Tomcat 10 would be allowed to just have both classes/interfaces for compatibility Also this would be a big hurdle moving forwards (and not sure if everything is really an interface and if there are no concrete classes in the spec) But for tomcat 10 and maybe for tomcat 11 this would be a good migration path that it would just run both of them just as easy. But anyway we kind of have this Apache Tomcat® - Apache Tomcat Migration Tool for Jakarta EE Software Downloads <https://tomcat.apache.org/download-migration.cgi> or: "Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE based applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool <https://github.com/apache/tomcat-jakartaee-migration> which is also available as a separate download <https://tomcat.apache.org/download-migration.cgi> for off-line use." but i agree a bit with your sentiment, this is a major break, its kind of a new spec (they versioned it 4.0 to 5.0 but it kind of just a 1.0 again, starting over) So i also do think that the maintenance window of Tomcat 9 will be quite long, but tomcat versions are supported for quite some time, 8.5 is still supported and the first release was beginning of 2014. Tomcat 9 was 3 years later or so, so i guess it will be supported maybe even close to 2030... On Tue, 28 Dec 2021 at 16:00, Michael B Allen <iop...@gmail.com> wrote: > On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jcompag...@servoy.com> > wrote: > > > > Will that really work? > > No. > > Clearly I'm not paying attention because after reading surprisingly > little information about this fundamental incompatibility and > downloading and trying Tomcat 10, there is no way to use a > javax.servlet library or application with a jakarta.servlet app server > like Tomcat 10. So now I REALLY want to know if people actually use > Tomcat 10 and what the release policy will be going forward for Tomcat > 9. Is Tomcat 9 going to be maintained separately with security fixes > and such? > > There must be thousands of libraries and applications that cannot be > converted for various reasons. Even active open source projects are > probably going to punt on this. Think about how many github projects > there are with one guy using it for some thing at work and so he > doesn't want to make up some screwy build process that creates two > jars. This basically guarantees that people will be using Tomcat 9 for > many years. > > Also, correct me if I'm wrong but it seems to me that the two > interfaces should easily coexist. The Servlet interface is just that - > an interface. So just create an implementation of javax.servlet that > uses the jakarta.servlet code as it's implementation. In many cases > the code could literally be like: > > package javax.servlet.http; > > public class HttpServletRequestWrapper extends > jakarta.servlet.http.ServletRequestWrapper implements > HttpServletRequest > { > // nothing to see here > } > > The only code that might be different is details about sessions or > something that jakarta.servlet wants to do a little differently. But > in that case, the ability of OOP to override methods to selectively > change some behavior can be utilized well here. Unless something in > jakarta.servlet changes that fundamentally breaks compatibility with > javax.servlet, code using javax.servlet shouldn't know the difference. > And if something does change that breaks backward compatibility, that > would be a slightly frightening change in policy regarding backward > compatibility of Java code in general since just about any piece of > Java code written in literally the last 20 years will run on the > latest platform with only minor tweaks. > > The effort required for every product and project in the universe to > create a build process that generates two jars is massive compared to > the effort that would be required for Tomcat to support both > javax.servlet and jakarta.servlet even if it were difficult to do for > some reason I'm not seeing. > > Mike > > -- > Michael B Allen > Java Active Directory Integration > http://www.ioplex.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Johan Compagner Servoy
