Mark,
On 1/30/25 11:50 AM, Mark Thomas wrote:
We have discussed plans for extended Tomcat 9 support several times. It
is still probably a couple of years away but I thought it would be worth
starting the discussion again.
There are a wide range of options. This is a brain dump of the questions
I have been mulling over when considering options.
> > 1. Extended support requires back-porting of security fixes. What else
do we want to back-port. Bug fixes? New features?
2. Do we want to continue to support the APR connector? If we decide no,
we can also stop supporting Tomcat Native 1.x. Equally, if we keep APR
we'll need to keep making Native 1.x releases to pick up OpenSSL updates.
See my response to #5 below.
3. What minimum version of Java do we want to support? Stick with Java
8? Increase the minimum version in line with availability of free
supported JREs (e.g. from Temurin)? Something else?
There are some shops who are petrified to change *anything* including
the JVM running their old servlet containers. Sure, some minor things
have changed within the JVM itself but really things should mostly work
with Java 24 that were working in Java 8. The biggest headache I've seen
has been adding --adds-opens and things like that to keep things working.
4. Do we cancel plans for extended Tomcat 9 support? (I'm not a fan of
this.)
-0.5
5. Do we effectively just continue with 9.0.x or create 9.?.x?
My first question would be "what guarantees have we made for Tomcat
9.0.x that we might want to adjust, requiring a 9.1.x or similar?" I
know some of these "guarantees" might actually be more traditions and
not policies, but I would guess that downstream users have come to
expect certain things from this project, and I believe we should
continue to honor those traditions.
6. Do we continue from 9.0.x or do we start from 10.1.x and revert the
Jakarta EE API changes?
I don't think I can make a useful contribution this decision.
I suspect the folks that want extended 9.0.x support also want minimal
changes. If we do plan on changing things (minimum Java version,
dropping APR) we should provide plenty of notice.
The two available migration tools (Tomcat and Eclipse) are quite good,
though I haven't used them extensively. The fact that you should be able
to deploy a JavaEE web application into Tomcat 10 or later should be the
preferred upgrade path for anyone who doesn't want to actually port
their application.
I would consider it a bug if Tomcat's migration tool wouldn't allow an
application to be deployed into Tomcat 10+ and continue to work, barring
any API incompatibilities. Such incompatibilities are currently minimal
but will grow over time. Fortunately, search-and-replace on a code base
should effectively perform the same duty on source that Tomcat performs
on binaries. Is there any reason the Tomcat Migration Tool couldn't be
used on *source* artifacts?
When do we think extended support will start? My best guess is no
earlier than 31 March 2027.
This will mostly be tied to the next Jakarta EE release / Tomcat 12, right?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
