I haven't seen any further discussion so I am going to draft an
announcement for review that I'll post this list.
Mark
On 04/02/2025 21:14, Christopher Schultz wrote:
Mark,
On 2/3/25 11:00 AM, Mark Thomas wrote:
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
+3
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
+1
- EOL 9.0.x no earlier than 31 March 2027 (based on Jakarta EE 12
release dates)
+1
- 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
+1
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.
+1 !
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
