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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
