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-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
