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

Reply via email to