On 28/12/2021 14:58, Michael B Allen 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.
Yes there is. Just place the Java EE web application in the
webapps-javaee directory and Tomcat will convert automatically to
Jakarta EE and then deploy it.
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?
It is the intention of the Tomcat community to continue to support
Tomcat 9 for as long as there are users that want a supported Java EE
platform.
Normally, we support 3 versions in parallel with a major version
reaching EOL every ~3 years. Typically a major version will be supported
for ~10 years.
Tomcat 9 will be different. When Tomcat 9 reaches the normal EOL point
(roughly 2027) 9.0.x releases will stop but Tomcat 9.10.x releases will
start. These will essentially track Tomcat 10.x releases but with the
Java EE API rather than the Jakarta EE API.
When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
and 9.11.x releases will start. These will essentially track Tomcat 11.x
releases but with the Java EE API rather than the Jakarta EE API.
And so on for as long as there is community demand for the Java EE
support and there are 3 Tomcat PMC members willing to vote for the release.
There must be thousands of libraries and applications that cannot be
converted for various reasons.
The only application I haven't been able to convert so far was Jira -
primarily because the error messages when Jira failed to start were
extremely unhelpful. I'm fairly sure the conversion process was missing
some OSGI config somewhere but I couldn't figure out what it was.
If anyone has an app that the conversion tool doesn't handle correctly,
open a bug, tell us what it isn't getting right and we should be able to
fix it.
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.
No need for any build process changes if you don't want to. Just use
webapps-javaee and the automatic conversion.
If there are apps that genuinely can't migrate (and I have a hard time
believing there are really any apps in this category) then Tomcat 9 will
continue to be available.
Also, correct me if I'm wrong but it seems to me that the two
interfaces should easily coexist.
Consider yourself corrected.
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
}
This illustrates the my point. You would not be able to cast an instance
of javax.servlet.http.HttpServletRequestWrapper to
javax.servlet.http.ServletRequestWrapper
Alternatively, just try and write a class (that compiles) that
implements javax.servlet.http.HttpServletRequest and
jakarta.servlet.http.HttpServletRequest
You can't. Well, you might be able to do get it to work with dynamic
proxies but the complexity would not be pretty - and I don't think you
could hide it from the web application which defeats the point of trying.
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.
It is much, much more complicated than that.
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.
Yes and no. The Java team is making some more invasive changes. The
removal of the security manager is the one that jumps immediately to mind.
Ignoring the package change, the biggest difference in Servlet 6 and the
other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
code has been removed.
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.
Yes, a Tomcat (or any container) based solution is more efficient. Hence
webapps-javaee and automatic conversion.
The solution you are proposing isn't viable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
