You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2023/01/11 11:23:35 UTC
Tomcat 11 - minimum Java version
Hi all,
The Jakarta EE platform group has announced that the minimum Java
version for Jakarta EE 11 will be Java 21. [1]
Given that the Java SecurityManager was deprecated in Java 17 and
planned for removal I intend to remove all references to the
SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
We would normally make Java 21 the minimum Java version. Given that Java
21 is still in EA, I don't plan to do that yet.
We could switch all branches to Java 17 as the the default build JRE now
as that supports targeting Java 7 onwards. That would allow us to easily
use some newer Java features in Tomcat 11 whilst still only requiring
RMs to use a single JDK version. If there are no objections I'll do this
shortly.
Java 21 supports targeting Java 8 onwards which means we won't be able
to switch to that when available for all branches unless Tomcat 8.5.x
has already reached EOL.
The target date for Jakarta EE 11 is Q1 2024. Given that there are no
Java 21 features we want to use in Tomcat 11 right now I suggest we wait
until we need to build Tomcat 11 with Java 21 to decide what to do.
Worst case, we'll need to build most branches with Java 21 and 8.5.x
with Java 17 until 8.5.x reaches EOL (31 March 2024).
I don't think there are any other immediate implications for Tomcat 11.
I'll continue to track the changes in the various specifications. The
summary at the moment is:
- removal of SecurityManager references from all
- servlet
- minor improvements / new features
- lots of clarifications of the Async API
- possible new low level HTTP API but not much movement so far
- EL
- removing reference to JavaBean spec is largish piece of work
- JSP
- no plans other than necessary updates triggered by changes in
EL/Servlet
- WebSocket
- minor improvements / new features
- clarifications
Mark
[1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 11/01/2023 16:09, Romain Manni-Bucau wrote:
> Side question from an user standpoint: does it mean tomcat 11 must not be
> used today too since it will abruptally switch its baseline (potentially
> against the app baseline)? Isnt it against the 11 releases idea? Thinking
> out loud and understanding jakarta decision is likely "weird"/inconsistent
> but not toncat responsability but think the point is valid for tomcat
> community which was happy to get early accesses AFAIK (at least i was in
> that camp).
Tomcat 11 releases are clearly marked as Milestone releases of Alpha
quality. Changes to the API - including minimum Java versions should be
expected.
Mark
>
> Le mer. 11 janv. 2023 à 17:01, Christopher Schultz <
> chris@christopherschultz.net> a écrit :
>
>> Mark,
>>
>> On 1/11/23 06:23, Mark Thomas wrote:
>>> The Jakarta EE platform group has announced that the minimum Java
>>> version for Jakarta EE 11 will be Java 21. [1]
>>>
>>> Given that the Java SecurityManager was deprecated in Java 17 and
>>> planned for removal I intend to remove all references to the
>>> SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
>>
>> +0
>>
>> This will complicate back-ports, but I suppose we must do it sometime.
>>
>>> We would normally make Java 21 the minimum Java version. Given that Java
>>> 21 is still in EA, I don't plan to do that yet.
>>>
>>> We could switch all branches to Java 17 as the the default build JRE now
>>> as that supports targeting Java 7 onwards. That would allow us to easily
>>> use some newer Java features in Tomcat 11 whilst still only requiring
>>> RMs to use a single JDK version. If there are no objections I'll do this
>>> shortly.
>>
>> Sure.
>>
>>> Java 21 supports targeting Java 8 onwards which means we won't be able
>>> to switch to that when available for all branches unless Tomcat 8.5.x
>>> has already reached EOL.
>>>
>>> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
>>> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
>>> until we need to build Tomcat 11 with Java 21 to decide what to do.
>>> Worst case, we'll need to build most branches with Java 21 and 8.5.x
>>> with Java 17 until 8.5.x reaches EOL (31 March 2024).
>>
>> On 1/11/23 08:00, Mark Thomas wrote:
>> > At the moment, I see the drivers for Java 21 as:
>> > - use new APIs (applications can do this even if the minimum version
>> > supported is lower)
>> > - non-preview versions of Panama and Loom (if available)
>>
>> I agree with Tim: If Jakarta EE 11 "requires" Java 21 (even if there are
>> no binary reasons why that is the case), then I think it's appropriate
>> to use that for builds and an API baseline. If we got a complaint from a
>> user that their application running on Tomcat 11 was failing due to some
>> weirdness in the application that was obviously caused by running it on
>> Java 11 or whatever, we'd first tell them that they must be using Java
>> 21, per spec. There is no reason to support Tomcat 11 in a pre-Java-21
>> environment, so let's go ahead and use Java 21 for the whole process.
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Side question from an user standpoint: does it mean tomcat 11 must not be
used today too since it will abruptally switch its baseline (potentially
against the app baseline)? Isnt it against the 11 releases idea? Thinking
out loud and understanding jakarta decision is likely "weird"/inconsistent
but not toncat responsability but think the point is valid for tomcat
community which was happy to get early accesses AFAIK (at least i was in
that camp).
Le mer. 11 janv. 2023 à 17:01, Christopher Schultz <
chris@christopherschultz.net> a écrit :
> Mark,
>
> On 1/11/23 06:23, Mark Thomas wrote:
> > The Jakarta EE platform group has announced that the minimum Java
> > version for Jakarta EE 11 will be Java 21. [1]
> >
> > Given that the Java SecurityManager was deprecated in Java 17 and
> > planned for removal I intend to remove all references to the
> > SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
>
> +0
>
> This will complicate back-ports, but I suppose we must do it sometime.
>
> > We would normally make Java 21 the minimum Java version. Given that Java
> > 21 is still in EA, I don't plan to do that yet.
> >
> > We could switch all branches to Java 17 as the the default build JRE now
> > as that supports targeting Java 7 onwards. That would allow us to easily
> > use some newer Java features in Tomcat 11 whilst still only requiring
> > RMs to use a single JDK version. If there are no objections I'll do this
> > shortly.
>
> Sure.
>
> > Java 21 supports targeting Java 8 onwards which means we won't be able
> > to switch to that when available for all branches unless Tomcat 8.5.x
> > has already reached EOL.
> >
> > The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> > Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> > until we need to build Tomcat 11 with Java 21 to decide what to do.
> > Worst case, we'll need to build most branches with Java 21 and 8.5.x
> > with Java 17 until 8.5.x reaches EOL (31 March 2024).
>
> On 1/11/23 08:00, Mark Thomas wrote:
> > At the moment, I see the drivers for Java 21 as:
> > - use new APIs (applications can do this even if the minimum version
> > supported is lower)
> > - non-preview versions of Panama and Loom (if available)
>
> I agree with Tim: If Jakarta EE 11 "requires" Java 21 (even if there are
> no binary reasons why that is the case), then I think it's appropriate
> to use that for builds and an API baseline. If we got a complaint from a
> user that their application running on Tomcat 11 was failing due to some
> weirdness in the application that was obviously caused by running it on
> Java 11 or whatever, we'd first tell them that they must be using Java
> 21, per spec. There is no reason to support Tomcat 11 in a pre-Java-21
> environment, so let's go ahead and use Java 21 for the whole process.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 11 - minimum Java version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 1/11/23 06:23, Mark Thomas wrote:
> The Jakarta EE platform group has announced that the minimum Java
> version for Jakarta EE 11 will be Java 21. [1]
>
> Given that the Java SecurityManager was deprecated in Java 17 and
> planned for removal I intend to remove all references to the
> SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
+0
This will complicate back-ports, but I suppose we must do it sometime.
> We would normally make Java 21 the minimum Java version. Given that Java
> 21 is still in EA, I don't plan to do that yet.
>
> We could switch all branches to Java 17 as the the default build JRE now
> as that supports targeting Java 7 onwards. That would allow us to easily
> use some newer Java features in Tomcat 11 whilst still only requiring
> RMs to use a single JDK version. If there are no objections I'll do this
> shortly.
Sure.
> Java 21 supports targeting Java 8 onwards which means we won't be able
> to switch to that when available for all branches unless Tomcat 8.5.x
> has already reached EOL.
>
> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> until we need to build Tomcat 11 with Java 21 to decide what to do.
> Worst case, we'll need to build most branches with Java 21 and 8.5.x
> with Java 17 until 8.5.x reaches EOL (31 March 2024).
On 1/11/23 08:00, Mark Thomas wrote:
> At the moment, I see the drivers for Java 21 as:
> - use new APIs (applications can do this even if the minimum version
> supported is lower)
> - non-preview versions of Panama and Loom (if available)
I agree with Tim: If Jakarta EE 11 "requires" Java 21 (even if there are
no binary reasons why that is the case), then I think it's appropriate
to use that for builds and an API baseline. If we got a complaint from a
user that their application running on Tomcat 11 was failing due to some
weirdness in the application that was obviously caused by running it on
Java 11 or whatever, we'd first tell them that they must be using Java
21, per spec. There is no reason to support Tomcat 11 in a pre-Java-21
environment, so let's go ahead and use Java 21 for the whole process.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 11/01/2023 11:49, Romain Manni-Bucau wrote:
> Hi,
>
> As an user we are adopting Tomcat 11 (even if still "on the edge") with
> Java 17 (in particular for some lib/stacks) and the more reactive servlet
> 6.1 is very interesting so hope it can be made Java 17 compliant until
> technically blocked.
Chatting with the Spring folks at $dayjob, they expressed the view that
Java 17 was likely to be the baseline for corporate users for a long
time to come.
At the moment, I see the drivers for Java 21 as:
- use new APIs (applications can do this even if the minimum version
supported is lower)
- non-preview versions of Panama and Loom (if available)
Are there are other API changes introduced between Java 17 and Java 21
that we would want to make use of?
JreCompat has a Java 19 instance but that is just controlling whether or
not to work around a bug.
Given the plan was to switch to Java 17 for building shortly and Java 21
later we don't need to make a final decision now (although gathering
views and data now is a good thing). We could switch the minimum version
for Tomcat 11 to Java 17 now and wait and see for Java 21. We'd have
from when Java 21 is released to when Tomcat 11 is declared stable to
decide whether to move the Java 21 as the minimum version.
Mark
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 11 janv. 2023 à 12:44, Mark Thomas <ma...@apache.org> a écrit :
>
>> On 11/01/2023 11:38, Rémy Maucherat wrote:
>>> On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>>
>> <snip/>
>>
>>>> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
>>>> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
>>>> until we need to build Tomcat 11 with Java 21 to decide what to do.
>>>> Worst case, we'll need to build most branches with Java 21 and 8.5.x
>>>> with Java 17 until 8.5.x reaches EOL (31 March 2024).
>>>
>>> If Java 21 is the baseline, I would like to propose to drop
>>> tomcat-native from Tomcat 11 and replace it with Panama. This is of
>>> course assuming Panama is non preview in 21, and this also needs to
>>> wait for some time (probably until June).
>>
>> Just playing devils advocate for a second, is Java 21 going to be too
>> big a leap for the majority of users? Might the Tomcat community be
>> better with Java 17 as the minimum version for Tomcat 11?
>>
>> Personally, I am in favour of Java 21 for Tomcat 11. There is always
>> Tomcat 10.1x for those that don't want to / can't move to Java 21. But I
>> did at least want to ask the question in case my views are in the minority.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
As an user we are adopting Tomcat 11 (even if still "on the edge") with
Java 17 (in particular for some lib/stacks) and the more reactive servlet
6.1 is very interesting so hope it can be made Java 17 compliant until
technically blocked.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 11 janv. 2023 à 12:44, Mark Thomas <ma...@apache.org> a écrit :
> On 11/01/2023 11:38, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>
> <snip/>
>
> >> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> >> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> >> until we need to build Tomcat 11 with Java 21 to decide what to do.
> >> Worst case, we'll need to build most branches with Java 21 and 8.5.x
> >> with Java 17 until 8.5.x reaches EOL (31 March 2024).
> >
> > If Java 21 is the baseline, I would like to propose to drop
> > tomcat-native from Tomcat 11 and replace it with Panama. This is of
> > course assuming Panama is non preview in 21, and this also needs to
> > wait for some time (probably until June).
>
> Just playing devils advocate for a second, is Java 21 going to be too
> big a leap for the majority of users? Might the Tomcat community be
> better with Java 17 as the minimum version for Tomcat 11?
>
> Personally, I am in favour of Java 21 for Tomcat 11. There is always
> Tomcat 10.1x for those that don't want to / can't move to Java 21. But I
> did at least want to ask the question in case my views are in the minority.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 11 - minimum Java version
Posted by Tim Funk <fu...@apache.org>.
On Wed, Jan 11, 2023 at 6:44 AM Mark Thomas <ma...@apache.org> wrote:
> On 11/01/2023 11:38, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>
> <snip/>
>
> Just playing devils advocate for a second, is Java 21 going to be too
> big a leap for the majority of users? Might the Tomcat community be
> better with Java 17 as the minimum version for Tomcat 11?
>
>
From a sysadmin and app developer perspective .... I have a feeling Tomcat
9 will linger for a very long time due to the javax -> jakarta migration.
To jump from 9-->11 requires that migration. So additionally requiring Java
21 doesn't seem like a horrible barrier.
-Tim
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jan 11, 2023 at 12:44 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 11/01/2023 11:38, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>
> <snip/>
>
> >> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> >> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> >> until we need to build Tomcat 11 with Java 21 to decide what to do.
> >> Worst case, we'll need to build most branches with Java 21 and 8.5.x
> >> with Java 17 until 8.5.x reaches EOL (31 March 2024).
> >
> > If Java 21 is the baseline, I would like to propose to drop
> > tomcat-native from Tomcat 11 and replace it with Panama. This is of
> > course assuming Panama is non preview in 21, and this also needs to
> > wait for some time (probably until June).
>
> Just playing devils advocate for a second, is Java 21 going to be too
> big a leap for the majority of users? Might the Tomcat community be
> better with Java 17 as the minimum version for Tomcat 11?
>
> Personally, I am in favour of Java 21 for Tomcat 11. There is always
> Tomcat 10.1x for those that don't want to / can't move to Java 21. But I
> did at least want to ask the question in case my views are in the minority.
If the upgrade requirement is there for a good reason, then it helps.
OTOH about Panama, branch 10.1 and 9.0 would get support (although
optional, in some way that has yet to be determined), tomcat-native
will be supported there as well anyway, so staying with Java 17 is ok
too. The main difference is that moving to Java 21 faster would likely
shorten the support period for tomcat-native by one release cycle,
which would be nice.
Rémy
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 11/01/2023 11:38, Rémy Maucherat wrote:
> On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
<snip/>
>> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
>> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
>> until we need to build Tomcat 11 with Java 21 to decide what to do.
>> Worst case, we'll need to build most branches with Java 21 and 8.5.x
>> with Java 17 until 8.5.x reaches EOL (31 March 2024).
>
> If Java 21 is the baseline, I would like to propose to drop
> tomcat-native from Tomcat 11 and replace it with Panama. This is of
> course assuming Panama is non preview in 21, and this also needs to
> wait for some time (probably until June).
Just playing devils advocate for a second, is Java 21 going to be too
big a leap for the majority of users? Might the Tomcat community be
better with Java 17 as the minimum version for Tomcat 11?
Personally, I am in favour of Java 21 for Tomcat 11. There is always
Tomcat 10.1x for those that don't want to / can't move to Java 21. But I
did at least want to ask the question in case my views are in the minority.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>
> Hi all,
>
> The Jakarta EE platform group has announced that the minimum Java
> version for Jakarta EE 11 will be Java 21. [1]
Oh wow, big surprise.
> Given that the Java SecurityManager was deprecated in Java 17 and
> planned for removal I intend to remove all references to the
> SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
>
> We would normally make Java 21 the minimum Java version. Given that Java
> 21 is still in EA, I don't plan to do that yet.
+1
> We could switch all branches to Java 17 as the the default build JRE now
> as that supports targeting Java 7 onwards. That would allow us to easily
> use some newer Java features in Tomcat 11 whilst still only requiring
> RMs to use a single JDK version. If there are no objections I'll do this
> shortly.
Ok.
> Java 21 supports targeting Java 8 onwards which means we won't be able
> to switch to that when available for all branches unless Tomcat 8.5.x
> has already reached EOL.
>
> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> until we need to build Tomcat 11 with Java 21 to decide what to do.
> Worst case, we'll need to build most branches with Java 21 and 8.5.x
> with Java 17 until 8.5.x reaches EOL (31 March 2024).
If Java 21 is the baseline, I would like to propose to drop
tomcat-native from Tomcat 11 and replace it with Panama. This is of
course assuming Panama is non preview in 21, and this also needs to
wait for some time (probably until June).
> I don't think there are any other immediate implications for Tomcat 11.
> I'll continue to track the changes in the various specifications. The
> summary at the moment is:
> - removal of SecurityManager references from all
> - servlet
> - minor improvements / new features
> - lots of clarifications of the Async API
> - possible new low level HTTP API but not much movement so far
> - EL
> - removing reference to JavaBean spec is largish piece of work
> - JSP
> - no plans other than necessary updates triggered by changes in
> EL/Servlet
> - WebSocket
> - minor improvements / new features
> - clarifications
Rémy
> Mark
>
> [1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Sat, May 13, 2023 at 10:48 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 12/05/2023 22:24, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
> >> We would normally make Java 21 the minimum Java version. Given that Java
> >> 21 is still in EA, I don't plan to do that yet.
> >
> > Since the update to Java 21 has now been made and seems to make
> > everyone happy, I would like to discuss Panama.
> >
> > - Panama as it is right now removes the need for tomcat-native 2.0. It
> > is stable, fast enough, works out of the box, is much much better for
> > cloud environments (no funny custom binary to add, only the usual
> > Java), and so on. Actually, all of these statements were already true
> > with Java 17, although the API was a bit rougher. Unfortunately at the
> > moment, it is still preview in Java 21.
> > - It is possible to include the support right now, but since the API
> > would change in Java 22, then Tomcat 11 (or at least that feature)
> > would only target Java 21. Compilation would have to occur on Java 21.
> > - Support for Java 21 ends in 2028. This means then there would be a
> > needed API update to Java LTS.next, dropping support for Java 21 (for
> > that feature), and causing a more complex build (targeting Java 21
> > with a newer Panama API would cause the compiler to scream).
> > - Multi release JARs are an option, but this is annoying as it would
> > require multiple Java versions to build Tomcat (since it is a preview
> > API), then assemble the multi release JAR. Not looking too good ...
> >
> > Given all this, there are two main options:
> > A) (unfortunately) *not* including the Panama support until it is non
> > preview. Once this happens, then my proposal would be to update the
> > minimum build Java version (not runtime !) for Tomcat 11, add the
> > Panama "final API" support, and use the release option to still target
> > 21 (except for the Panama feature classes, of course, which would be
> > compiled separately). Also as a consequence tomcat-native 2 would have
> > to be supported for the entire lifecycle of Tomcat 11.
> > B) Add full support using Java 21, drop tomcat-native. Once Java
> > LTS.next is released towards the end of 2025 (with non preview Panama,
> > hopefully), update to use the new API. Users of OpenSSL will have to
> > move to Java LTS.next
> >
> > Although I would like B), A) seems more reasonable and in line with
> > our support practices.
> >
> > Comments ?
>
> Is there any chance Panama will come out of preview in Java 21?
I doubt it, the jep has been filed as a preview.
https://openjdk.org/jeps/442
This is disappointing since the progress since 19 has been small.
> OpenSSL supports versions for less time than the typical support period
> for a major Tomcat version (10 years). And then you have the Linux
> distributions that have specific OpenSSL versions and their support
> periods. With Tomcat Native we have been able to manage this reasonably
> well without too much maintenance burden for us.
>
> How would this work with different versions of OpenSSL? Is it possible
> to support multiple OpenSSL versions?
I did it as an experiment with 1.1 and 3.0, and there's no real
problem since OpenSSL is rather conservative with API changes.
Technically, there are more changes than normally needed since the
functional macros that are introduced for API compatibility in the
OpenSSL code do not work for Panama.
> Of the two options you present, I agree that option A is more in-line
> with how we typically do things (as much as I would like to say goodbye
> to native code).
+1
Rémy
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, May 18, 2023, 06:50 Mark Thomas <ma...@apache.org> wrote:
>
> 17 May 2023 20:37:01 Christopher Schultz <ch...@christopherschultz.net>:
>
> > On 5/17/23 04:52, Mark Thomas wrote:
>
> >> Once we switch to using Panama, we are going to have to figure out how
> >> to handle this. My primary concern is new features that depend on API
> >> calls only present in newer OpenSSL versions.
> >
> > The Java components can query the OpenSSL API level from the library
> > and make decisions based on that. It won't be a compile-time decision
> > any more, which IMO is actually a good thing.
>
> Ah, I didn't know that. Nice. I need to read up on Panama.
>
The code actually supports both OpenSSL 1.1 and 3.0 (for fips im
particular, but there are a couple others due to macros not working), as an
experiment on how to deal with differences. Works good (at runtime, not at
compile time).
Also in other news, Panama is confirmed as preview in Java 21, so I'm
disappointed.
Rémy
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
17 May 2023 20:37:01 Christopher Schultz <ch...@christopherschultz.net>:
> On 5/17/23 04:52, Mark Thomas wrote:
>> Once we switch to using Panama, we are going to have to figure out how
>> to handle this. My primary concern is new features that depend on API
>> calls only present in newer OpenSSL versions.
>
> The Java components can query the OpenSSL API level from the library
> and make decisions based on that. It won't be a compile-time decision
> any more, which IMO is actually a good thing.
Ah, I didn't know that. Nice. I need to read up on Panama.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 5/17/23 04:52, Mark Thomas wrote:
> On 16/05/2023 18:12, koteswara Rao Gundapaneni wrote:
>> To service the SSL tomcat end users are now engaged mostly with HTTPD
>> SERVER and IBM HTTPD
>
> I don't think that is the case.
>
> Yes, lots of Tomcat instances are behind reverse proxies and yes, lots
> of those reverse proxies are terminating TLS but there is still a high
> demand for Tomcat to be able to terminate TLS since:
>
> - Some users are happy running Tomcat without a reverse proxy.
>
> - Many users use Tomcat in environments (e.g. banking) where it is a
> requirement that the channel between the reverse proxy and Tomcat uses
> TLS.
+1
Nobody should be using unencrypted network connections for anything they
care about. Even on a "trusted" network.
> Also, if I had to list the most commonly used proxies, I don't think
> IBM's HTTP server would be on that list. httpd, ATS, NginX and F5 are
> the first few that come to mind.
>
>> If we look at the c,c++,etc API vendors they rarely change thier
>> Products production at user level
>
> Yes, but.
>
> The timescales were are talking about here are large - at least for
> software. The average Tomcat release is supported for 10 years. Factor
> in LTS policies of Linux distributions such as Debian and Ubuntu and you
> can easily get to timescales in the 15-20 year range.
>
> The OpenSSL API that Tomcat Native uses has been very stable over an
> extended time frame but even with that we have had to use #ifdef
> directives and the like to have a single code base that can be used with
> multiple versions - often related to access to new features.
>
> Once we switch to using Panama, we are going to have to figure out how
> to handle this. My primary concern is new features that depend on API
> calls only present in newer OpenSSL versions.
The Java components can query the OpenSSL API level from the library and
make decisions based on that. It won't be a compile-time decision any
more, which IMO is actually a good thing.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 16/05/2023 18:12, koteswara Rao Gundapaneni wrote:
> To service the SSL tomcat end users are now engaged mostly with HTTPD
> SERVER and IBM HTTPD
I don't think that is the case.
Yes, lots of Tomcat instances are behind reverse proxies and yes, lots
of those reverse proxies are terminating TLS but there is still a high
demand for Tomcat to be able to terminate TLS since:
- Some users are happy running Tomcat without a reverse proxy.
- Many users use Tomcat in environments (e.g. banking) where it is a
requirement that the channel between the reverse proxy and Tomcat uses
TLS.
Also, if I had to list the most commonly used proxies, I don't think
IBM's HTTP server would be on that list. httpd, ATS, NginX and F5 are
the first few that come to mind.
> If we look at the c,c++,etc API vendors they rarely change thier
> Products production at user level
Yes, but.
The timescales were are talking about here are large - at least for
software. The average Tomcat release is supported for 10 years. Factor
in LTS policies of Linux distributions such as Debian and Ubuntu and you
can easily get to timescales in the 15-20 year range.
The OpenSSL API that Tomcat Native uses has been very stable over an
extended time frame but even with that we have had to use #ifdef
directives and the like to have a single code base that can be used with
multiple versions - often related to access to new features.
Once we switch to using Panama, we are going to have to figure out how
to handle this. My primary concern is new features that depend on API
calls only present in newer OpenSSL versions.
Mark
>
>
>
>
> On Sat, May 13, 2023 at 1:48 AM Mark Thomas <ma...@apache.org> wrote:
>
>> On 12/05/2023 22:24, Rémy Maucherat wrote:
>>> On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>>>> We would normally make Java 21 the minimum Java version. Given that Java
>>>> 21 is still in EA, I don't plan to do that yet.
>>>
>>> Since the update to Java 21 has now been made and seems to make
>>> everyone happy, I would like to discuss Panama.
>>>
>>> - Panama as it is right now removes the need for tomcat-native 2.0. It
>>> is stable, fast enough, works out of the box, is much much better for
>>> cloud environments (no funny custom binary to add, only the usual
>>> Java), and so on. Actually, all of these statements were already true
>>> with Java 17, although the API was a bit rougher. Unfortunately at the
>>> moment, it is still preview in Java 21.
>>> - It is possible to include the support right now, but since the API
>>> would change in Java 22, then Tomcat 11 (or at least that feature)
>>> would only target Java 21. Compilation would have to occur on Java 21.
>>> - Support for Java 21 ends in 2028. This means then there would be a
>>> needed API update to Java LTS.next, dropping support for Java 21 (for
>>> that feature), and causing a more complex build (targeting Java 21
>>> with a newer Panama API would cause the compiler to scream).
>>> - Multi release JARs are an option, but this is annoying as it would
>>> require multiple Java versions to build Tomcat (since it is a preview
>>> API), then assemble the multi release JAR. Not looking too good ...
>>>
>>> Given all this, there are two main options:
>>> A) (unfortunately) *not* including the Panama support until it is non
>>> preview. Once this happens, then my proposal would be to update the
>>> minimum build Java version (not runtime !) for Tomcat 11, add the
>>> Panama "final API" support, and use the release option to still target
>>> 21 (except for the Panama feature classes, of course, which would be
>>> compiled separately). Also as a consequence tomcat-native 2 would have
>>> to be supported for the entire lifecycle of Tomcat 11.
>>> B) Add full support using Java 21, drop tomcat-native. Once Java
>>> LTS.next is released towards the end of 2025 (with non preview Panama,
>>> hopefully), update to use the new API. Users of OpenSSL will have to
>>> move to Java LTS.next
>>>
>>> Although I would like B), A) seems more reasonable and in line with
>>> our support practices.
>>>
>>> Comments ?
>>
>> Is there any chance Panama will come out of preview in Java 21?
>>
>> OpenSSL supports versions for less time than the typical support period
>> for a major Tomcat version (10 years). And then you have the Linux
>> distributions that have specific OpenSSL versions and their support
>> periods. With Tomcat Native we have been able to manage this reasonably
>> well without too much maintenance burden for us.
>>
>> How would this work with different versions of OpenSSL? Is it possible
>> to support multiple OpenSSL versions?
>>
>> Of the two options you present, I agree that option A is more in-line
>> with how we typically do things (as much as I would like to say goodbye
>> to native code).
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by koteswara Rao Gundapaneni <ko...@gmail.com>.
To service the SSL tomcat end users are now engaged mostly with HTTPD
SERVER and IBM HTTPD
If we look at the c,c++,etc API vendors they rarely change thier
Products production at user level - @Mark remarks
On Sat, May 13, 2023 at 1:48 AM Mark Thomas <ma...@apache.org> wrote:
> On 12/05/2023 22:24, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
> >> We would normally make Java 21 the minimum Java version. Given that Java
> >> 21 is still in EA, I don't plan to do that yet.
> >
> > Since the update to Java 21 has now been made and seems to make
> > everyone happy, I would like to discuss Panama.
> >
> > - Panama as it is right now removes the need for tomcat-native 2.0. It
> > is stable, fast enough, works out of the box, is much much better for
> > cloud environments (no funny custom binary to add, only the usual
> > Java), and so on. Actually, all of these statements were already true
> > with Java 17, although the API was a bit rougher. Unfortunately at the
> > moment, it is still preview in Java 21.
> > - It is possible to include the support right now, but since the API
> > would change in Java 22, then Tomcat 11 (or at least that feature)
> > would only target Java 21. Compilation would have to occur on Java 21.
> > - Support for Java 21 ends in 2028. This means then there would be a
> > needed API update to Java LTS.next, dropping support for Java 21 (for
> > that feature), and causing a more complex build (targeting Java 21
> > with a newer Panama API would cause the compiler to scream).
> > - Multi release JARs are an option, but this is annoying as it would
> > require multiple Java versions to build Tomcat (since it is a preview
> > API), then assemble the multi release JAR. Not looking too good ...
> >
> > Given all this, there are two main options:
> > A) (unfortunately) *not* including the Panama support until it is non
> > preview. Once this happens, then my proposal would be to update the
> > minimum build Java version (not runtime !) for Tomcat 11, add the
> > Panama "final API" support, and use the release option to still target
> > 21 (except for the Panama feature classes, of course, which would be
> > compiled separately). Also as a consequence tomcat-native 2 would have
> > to be supported for the entire lifecycle of Tomcat 11.
> > B) Add full support using Java 21, drop tomcat-native. Once Java
> > LTS.next is released towards the end of 2025 (with non preview Panama,
> > hopefully), update to use the new API. Users of OpenSSL will have to
> > move to Java LTS.next
> >
> > Although I would like B), A) seems more reasonable and in line with
> > our support practices.
> >
> > Comments ?
>
> Is there any chance Panama will come out of preview in Java 21?
>
> OpenSSL supports versions for less time than the typical support period
> for a major Tomcat version (10 years). And then you have the Linux
> distributions that have specific OpenSSL versions and their support
> periods. With Tomcat Native we have been able to manage this reasonably
> well without too much maintenance burden for us.
>
> How would this work with different versions of OpenSSL? Is it possible
> to support multiple OpenSSL versions?
>
> Of the two options you present, I agree that option A is more in-line
> with how we typically do things (as much as I would like to say goodbye
> to native code).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 12/05/2023 22:24, Rémy Maucherat wrote:
> On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
>> We would normally make Java 21 the minimum Java version. Given that Java
>> 21 is still in EA, I don't plan to do that yet.
>
> Since the update to Java 21 has now been made and seems to make
> everyone happy, I would like to discuss Panama.
>
> - Panama as it is right now removes the need for tomcat-native 2.0. It
> is stable, fast enough, works out of the box, is much much better for
> cloud environments (no funny custom binary to add, only the usual
> Java), and so on. Actually, all of these statements were already true
> with Java 17, although the API was a bit rougher. Unfortunately at the
> moment, it is still preview in Java 21.
> - It is possible to include the support right now, but since the API
> would change in Java 22, then Tomcat 11 (or at least that feature)
> would only target Java 21. Compilation would have to occur on Java 21.
> - Support for Java 21 ends in 2028. This means then there would be a
> needed API update to Java LTS.next, dropping support for Java 21 (for
> that feature), and causing a more complex build (targeting Java 21
> with a newer Panama API would cause the compiler to scream).
> - Multi release JARs are an option, but this is annoying as it would
> require multiple Java versions to build Tomcat (since it is a preview
> API), then assemble the multi release JAR. Not looking too good ...
>
> Given all this, there are two main options:
> A) (unfortunately) *not* including the Panama support until it is non
> preview. Once this happens, then my proposal would be to update the
> minimum build Java version (not runtime !) for Tomcat 11, add the
> Panama "final API" support, and use the release option to still target
> 21 (except for the Panama feature classes, of course, which would be
> compiled separately). Also as a consequence tomcat-native 2 would have
> to be supported for the entire lifecycle of Tomcat 11.
> B) Add full support using Java 21, drop tomcat-native. Once Java
> LTS.next is released towards the end of 2025 (with non preview Panama,
> hopefully), update to use the new API. Users of OpenSSL will have to
> move to Java LTS.next
>
> Although I would like B), A) seems more reasonable and in line with
> our support practices.
>
> Comments ?
Is there any chance Panama will come out of preview in Java 21?
OpenSSL supports versions for less time than the typical support period
for a major Tomcat version (10 years). And then you have the Linux
distributions that have specific OpenSSL versions and their support
periods. With Tomcat Native we have been able to manage this reasonably
well without too much maintenance burden for us.
How would this work with different versions of OpenSSL? Is it possible
to support multiple OpenSSL versions?
Of the two options you present, I agree that option A is more in-line
with how we typically do things (as much as I would like to say goodbye
to native code).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas <ma...@apache.org> wrote:
> We would normally make Java 21 the minimum Java version. Given that Java
> 21 is still in EA, I don't plan to do that yet.
Since the update to Java 21 has now been made and seems to make
everyone happy, I would like to discuss Panama.
- Panama as it is right now removes the need for tomcat-native 2.0. It
is stable, fast enough, works out of the box, is much much better for
cloud environments (no funny custom binary to add, only the usual
Java), and so on. Actually, all of these statements were already true
with Java 17, although the API was a bit rougher. Unfortunately at the
moment, it is still preview in Java 21.
- It is possible to include the support right now, but since the API
would change in Java 22, then Tomcat 11 (or at least that feature)
would only target Java 21. Compilation would have to occur on Java 21.
- Support for Java 21 ends in 2028. This means then there would be a
needed API update to Java LTS.next, dropping support for Java 21 (for
that feature), and causing a more complex build (targeting Java 21
with a newer Panama API would cause the compiler to scream).
- Multi release JARs are an option, but this is annoying as it would
require multiple Java versions to build Tomcat (since it is a preview
API), then assemble the multi release JAR. Not looking too good ...
Given all this, there are two main options:
A) (unfortunately) *not* including the Panama support until it is non
preview. Once this happens, then my proposal would be to update the
minimum build Java version (not runtime !) for Tomcat 11, add the
Panama "final API" support, and use the release option to still target
21 (except for the Panama feature classes, of course, which would be
compiled separately). Also as a consequence tomcat-native 2 would have
to be supported for the entire lifecycle of Tomcat 11.
B) Add full support using Java 21, drop tomcat-native. Once Java
LTS.next is released towards the end of 2025 (with non preview Panama,
hopefully), update to use the new API. Users of OpenSSL will have to
move to Java LTS.next
Although I would like B), A) seems more reasonable and in line with
our support practices.
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jan 19, 2023 at 10:01 AM Mark Thomas <ma...@apache.org> wrote:
>
> Hi all,
>
> As a result of the discussions and reminding myself of various issues I
> intend to proceed as follows:
>
> - Switch the minimum JRE to Java 17 for Tomcat 11. While Jakarta
> EE 11 permits a minimum of Java 21, we will decide later whether to
> increase the minimum Java version to 21 for Tomcat 11.
>
> - Switch the CI systems to build with Java 17 for all branches except
> Tomcat 8.5.x on buildbot since the version of ECJ we are restricted to
> for Tomcat 8.5.x has issues on Java 17 (BZ 65599).
>
> - I intend to leave the minimum build version as Java 11 for 8.5.x,
> 9.0.x and 10.1.x as there is no driver to increase that at this time
+1
I plan to keep on building 9.0 with Java 11 for now (no incentive to
update yet).
Rémy
> Mark
>
>
> On 11/01/2023 11:23, Mark Thomas wrote:
> > Hi all,
> >
> > The Jakarta EE platform group has announced that the minimum Java
> > version for Jakarta EE 11 will be Java 21. [1]
> >
> > Given that the Java SecurityManager was deprecated in Java 17 and
> > planned for removal I intend to remove all references to the
> > SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
> >
> > We would normally make Java 21 the minimum Java version. Given that Java
> > 21 is still in EA, I don't plan to do that yet.
> >
> > We could switch all branches to Java 17 as the the default build JRE now
> > as that supports targeting Java 7 onwards. That would allow us to easily
> > use some newer Java features in Tomcat 11 whilst still only requiring
> > RMs to use a single JDK version. If there are no objections I'll do this
> > shortly.
> >
> > Java 21 supports targeting Java 8 onwards which means we won't be able
> > to switch to that when available for all branches unless Tomcat 8.5.x
> > has already reached EOL.
> >
> > The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> > Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> > until we need to build Tomcat 11 with Java 21 to decide what to do.
> > Worst case, we'll need to build most branches with Java 21 and 8.5.x
> > with Java 17 until 8.5.x reaches EOL (31 March 2024).
> >
> > I don't think there are any other immediate implications for Tomcat 11.
> > I'll continue to track the changes in the various specifications. The
> > summary at the moment is:
> > - removal of SecurityManager references from all
> > - servlet
> > - minor improvements / new features
> > - lots of clarifications of the Async API
> > - possible new low level HTTP API but not much movement so far
> > - EL
> > - removing reference to JavaBean spec is largish piece of work
> > - JSP
> > - no plans other than necessary updates triggered by changes in
> > EL/Servlet
> > - WebSocket
> > - minor improvements / new features
> > - clarifications
> >
> > Mark
> >
> > [1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
Hi all,
As a result of the discussions and reminding myself of various issues I
intend to proceed as follows:
- Switch the minimum JRE to Java 17 for Tomcat 11. While Jakarta
EE 11 permits a minimum of Java 21, we will decide later whether to
increase the minimum Java version to 21 for Tomcat 11.
- Switch the CI systems to build with Java 17 for all branches except
Tomcat 8.5.x on buildbot since the version of ECJ we are restricted to
for Tomcat 8.5.x has issues on Java 17 (BZ 65599).
- I intend to leave the minimum build version as Java 11 for 8.5.x,
9.0.x and 10.1.x as there is no driver to increase that at this time
Mark
On 11/01/2023 11:23, Mark Thomas wrote:
> Hi all,
>
> The Jakarta EE platform group has announced that the minimum Java
> version for Jakarta EE 11 will be Java 21. [1]
>
> Given that the Java SecurityManager was deprecated in Java 17 and
> planned for removal I intend to remove all references to the
> SecurityManager from the Tomcat 11 code base. I plan to do this shortly.
>
> We would normally make Java 21 the minimum Java version. Given that Java
> 21 is still in EA, I don't plan to do that yet.
>
> We could switch all branches to Java 17 as the the default build JRE now
> as that supports targeting Java 7 onwards. That would allow us to easily
> use some newer Java features in Tomcat 11 whilst still only requiring
> RMs to use a single JDK version. If there are no objections I'll do this
> shortly.
>
> Java 21 supports targeting Java 8 onwards which means we won't be able
> to switch to that when available for all branches unless Tomcat 8.5.x
> has already reached EOL.
>
> The target date for Jakarta EE 11 is Q1 2024. Given that there are no
> Java 21 features we want to use in Tomcat 11 right now I suggest we wait
> until we need to build Tomcat 11 with Java 21 to decide what to do.
> Worst case, we'll need to build most branches with Java 21 and 8.5.x
> with Java 17 until 8.5.x reaches EOL (31 March 2024).
>
> I don't think there are any other immediate implications for Tomcat 11.
> I'll continue to track the changes in the various specifications. The
> summary at the moment is:
> - removal of SecurityManager references from all
> - servlet
> - minor improvements / new features
> - lots of clarifications of the Async API
> - possible new low level HTTP API but not much movement so far
> - EL
> - removing reference to JavaBean spec is largish piece of work
> - JSP
> - no plans other than necessary updates triggered by changes in
> EL/Servlet
> - WebSocket
> - minor improvements / new features
> - clarifications
>
> Mark
>
> [1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 11/01/2023 14:13, Michael Osipov wrote:
> While I cannot comment on Tomcat 11 requirements and Java 21 is
> unavoidable I'd like to comment on this because I consider it wrong:
>
>> We could switch all branches to Java 17 as the the default build JRE
>> now as that supports targeting Java 7 onwards. That would allow us to
>> easily use some newer Java features in Tomcat 11 whilst still only
>> requiring RMs to use a single JDK version. If there are no objections
>> I'll do this shortly.
>
> This will basically kill Tomcat 9.x and 10.x for those who:
> * Want/need to build from source
> * Run tests in their setup
> * Provide fixes/patches
> where Java 17 is not available for them, e.g. commercial Unix or any
> other circumstance (company policy, etc.). I already dislike the move
> done with Spring Framework 6/Boot 3, this just cuts off a tremendous
> user base.
>
> For as long as 8/11 [1] receive support I wouldn't do this step at all.
> I'd take the baseline the Java EE version requires.
Nothing in the proposed change stops you building with an earlier
version of Java. This is simply a change to the *default* build JRE.
To confirm, I just updated this locally to 17 for 9.0.x and then happily
completed both "ant clean deploy" and "ant release" using Java 11.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 12/01/2023 08:35, Rémy Maucherat wrote:
> On Wed, Jan 11, 2023 at 10:48 PM Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>>
>> Guess it was more about default java for linux distro, build is only
>> reproducible if target --release flag is <= java distro version which will
>> not be the case for java 21 soon enough probably, not really a build issue
>> by itself more an ecosystem one - distro consumming sources.
>
> If you want to reproduce the build for some reason, the
> build.properties.release file that is included in the tag needs to be
> looked at. The platform matters (trying to reproduce on Windows a
> release built on Linux will not work for example, according to what
> Mark said earlier), and the Java version does too, so all that
> information is there.
Correction: Build on Linux, reproduce on Windows works. As does the reverse.
Fixing reproducible builds across Java (and Ant) versions is doable and
is on my TODO list (somewhere near the middle at the moment).
Mark
>
> Rémy
>
>>
>> Le mer. 11 janv. 2023 à 21:41, Mark Thomas <ma...@apache.org> a écrit :
>>
>>> On 11/01/2023 20:15, Michael Osipov wrote:
>>>> Even if not, there is another problem with that: When you build with
>>>> Java 17, that build cannot be reproduced on Java 11 or 8 because class
>>>> file content will be different.
>>>
>>> Experience in the Tomcat project says otherwise.
>>>
>>> We can already reproduce builds across platforms. The current Tomcat
>>> builds are reproducible across Windows and Linux (and I suspect MacOS
>>> although I haven't tested that recently).
>>>
>>> We also know the only blocker to cross-Java version builds is the
>>> MANIFEST.MF content. The class files are identical.
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jan 11, 2023 at 10:48 PM Romain Manni-Bucau
<rm...@gmail.com> wrote:
>
> Guess it was more about default java for linux distro, build is only
> reproducible if target --release flag is <= java distro version which will
> not be the case for java 21 soon enough probably, not really a build issue
> by itself more an ecosystem one - distro consumming sources.
If you want to reproduce the build for some reason, the
build.properties.release file that is included in the tag needs to be
looked at. The platform matters (trying to reproduce on Windows a
release built on Linux will not work for example, according to what
Mark said earlier), and the Java version does too, so all that
information is there.
Rémy
>
> Le mer. 11 janv. 2023 à 21:41, Mark Thomas <ma...@apache.org> a écrit :
>
> > On 11/01/2023 20:15, Michael Osipov wrote:
> > > Even if not, there is another problem with that: When you build with
> > > Java 17, that build cannot be reproduced on Java 11 or 8 because class
> > > file content will be different.
> >
> > Experience in the Tomcat project says otherwise.
> >
> > We can already reproduce builds across platforms. The current Tomcat
> > builds are reproducible across Windows and Linux (and I suspect MacOS
> > although I haven't tested that recently).
> >
> > We also know the only blocker to cross-Java version builds is the
> > MANIFEST.MF content. The class files are identical.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Guess it was more about default java for linux distro, build is only
reproducible if target --release flag is <= java distro version which will
not be the case for java 21 soon enough probably, not really a build issue
by itself more an ecosystem one - distro consumming sources.
Le mer. 11 janv. 2023 à 21:41, Mark Thomas <ma...@apache.org> a écrit :
> On 11/01/2023 20:15, Michael Osipov wrote:
> > Even if not, there is another problem with that: When you build with
> > Java 17, that build cannot be reproduced on Java 11 or 8 because class
> > file content will be different.
>
> Experience in the Tomcat project says otherwise.
>
> We can already reproduce builds across platforms. The current Tomcat
> builds are reproducible across Windows and Linux (and I suspect MacOS
> although I haven't tested that recently).
>
> We also know the only blocker to cross-Java version builds is the
> MANIFEST.MF content. The class files are identical.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat 11 - minimum Java version
Posted by Mark Thomas <ma...@apache.org>.
On 11/01/2023 20:15, Michael Osipov wrote:
> Even if not, there is another problem with that: When you build with
> Java 17, that build cannot be reproduced on Java 11 or 8 because class
> file content will be different.
Experience in the Tomcat project says otherwise.
We can already reproduce builds across platforms. The current Tomcat
builds are reproducible across Windows and Linux (and I suspect MacOS
although I haven't tested that recently).
We also know the only blocker to cross-Java version builds is the
MANIFEST.MF content. The class files are identical.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Michael Osipov <mi...@apache.org>.
> On 11/01/2023 14:13, Michael Osipov wrote:
>> While I cannot comment on Tomcat 11 requirements and Java 21 is
>> unavoidable I'd like to comment on this because I consider it wrong:
>>
>>> We could switch all branches to Java 17 as the the default build JRE
>>> now as that supports targeting Java 7 onwards. That would allow us to
>>> easily use some newer Java features in Tomcat 11 whilst still only
>>> requiring RMs to use a single JDK version. If there are no objections
>>> I'll do this shortly.
>>
>> This will basically kill Tomcat 9.x and 10.x for those who:
>> * Want/need to build from source
>> * Run tests in their setup
>> * Provide fixes/patches
>> where Java 17 is not available for them, e.g. commercial Unix or any
>> other circumstance (company policy, etc.). I already dislike the move
>> done with Spring Framework 6/Boot 3, this just cuts off a tremendous
>> user base.
>>
>> For as long as 8/11 [1] receive support I wouldn't do this step at all.
>> I'd take the baseline the Java EE version requires.
>
> Nothing in the proposed change stops you building with an earlier
> version of Java. This is simply a change to the *default* build JRE.
>
> To confirm, I just updated this locally to 17 for 9.0.x and then happily
> completed both "ant clean deploy" and "ant release" using Java 11.
That wasn't really clear from your first mail. I understood that you
want to enfore to build with Java 17 although --release is 8.
Even if not, there is another problem with that: When you build with
Java 17, that build cannot be reproduced on Java 11 or 8 because class
file content will be different. At Maven we verify release votes with
the same OS class (Windows or POSIX-like) and Java 8. Having everything
produced with 17, well...still limits others.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Posted by Michael Osipov <mi...@apache.org>.
While I cannot comment on Tomcat 11 requirements and Java 21 is
unavoidable I'd like to comment on this because I consider it wrong:
> We could switch all branches to Java 17 as the the default build JRE now
> as that supports targeting Java 7 onwards. That would allow us to easily
> use some newer Java features in Tomcat 11 whilst still only requiring
> RMs to use a single JDK version. If there are no objections I'll do this
> shortly.
This will basically kill Tomcat 9.x and 10.x for those who:
* Want/need to build from source
* Run tests in their setup
* Provide fixes/patches
where Java 17 is not available for them, e.g. commercial Unix or any
other circumstance (company policy, etc.). I already dislike the move
done with Spring Framework 6/Boot 3, this just cuts off a tremendous
user base.
For as long as 8/11 [1] receive support I wouldn't do this step at all.
I'd take the baseline the Java EE version requires.
Michael
[1] https://endoflife.date/java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org