On Fri, Oct 20, 2023 at 12:17 PM Michael Osipov <micha...@apache.org> wrote: > > On 2023/10/20 07:30:04 Rémy Maucherat wrote: > > Hi, > > > > I am very pleased to report that after years of development, the > > Foreign Function & Memory API is (finally !) no longer a preview API. > > It is now available in build 20 of Java 22 where it can be used > > without the preview flag. > > Downloads: https://jdk.java.net/22/ > > > > Assuming Mark accepts working with an alpha build of Java 22 to > > produce the releases of Tomcat 11, it is now possible to merge the > > OpenSSL code. > > As a reminder, it is located here right now: > > https://github.com/apache/tomcat/tree/main/modules/openssl-foreign > > > > The idea is to build the two packages that need it using a 22 release > > target, while the rest would release target 21 as usual. Using some > > conditionals, it should be possible to allow casual building with 21, > > as it would be bad to drive away contributors who would understandably > > not be very interested in alpha Java 22 yet. I would also add the > > jextract scripts in res/jextract (using jextract at this time is going > > to remain harder however). > > > > "Final" Java 22 will occur next March around the time Jakarta EE 11 is > > supposed to be released, so this aligns to a large extent even in the > > unlikely event where there is no EE schedule slippage. > > > > As for actual use of the component, that's where things will hurt. > > Given the Java support schedules, this would basically be mostly > > unused until the next Java LTS release (probably 25, almost two years > > away). However, the support lifecycle of a Tomcat branch being what it > > is, it would still be relatively early in the Tomcat 11 lifecycle. And > > in the meantime it would give the component a lot of testing, with > > probably a significant amount of niche uses (containers ?). > > > > Comments ? > > This is actually good news! While I will take a look at your code at some > point ot learn how this new API works and learn from you, do you think that > it could live in a separate module (repo) which produces a JAR implementing > an interface then making it available to Tomat 11+ instead of making the > build more complex and conditional? >
That's what currently exists, the JAR built in the module can be used with Tomcat 9.0+ (SSLImplementation is the interface used). I believe the added temporary complexity to the build is small compared to the benefits. The obvious one is being able to avoid using tomcat-native out of the box, but there is also the possibility of using the quic API in the not too distant future. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
