Responding to all the threads here...
On 03/02/2025 13:40, Christopher Schultz wrote:
<snip/>
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.
Consensus appears to be that we continue supporting Tomcat 9 on Java 8.
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.
If seems that there might be support for dropping support for the
APR/Native connector.
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?
None. It should work. Converting *.java files is explicitly supported.
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?
Yes.
In summary, I think there is consensus for:
- continue Tomcat 9 releases on the same basis as we do currently
- continue with Java 8 as the minimum Java version
- announce our plans once we think we have something concrete
And potentially (separating this out so folks can object)
- Deprecate the APR/Native connector and advertise it will be removed in
9.1.x onwards
- EOL 9.0.x no earlier than 31 March 2027 (based on Jakarta EE 12
release dates)
- Provide LTS via 9.1.x which is 9.0.x less the APr/Native connector
with those components modified to be NO-OPs / log a warning /
automatically use NIO+OpenSSL instead as appropriate
If we can finalise this as a plan in the next few weeks that allows us
to get a notice out by 31 March this year providing at least 2 years
notice of 9.0.x's EOL and the plans for 9.1.x.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
