On Fri, Sep 13, 2024 at 4:46 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Mark,
>
> On 9/12/24 12:48, Mark Thomas wrote:
> > On 12/09/2024 15:15, Rémy Maucherat wrote:
> >> Hi,
> >>
> >> This JEP has the potential to have a significant impact with Tomcat's
> >> JNI use starting with Java 26.
> >> https://openjdk.org/jeps/471
> >>
> >> Unsafe.invokeCleaner will be removed, which will effectively prevent
> >> using the direct ByteBuffers that are needed for tomcat-native. The
> >> solution is to use a memory segment from FFM, then call
> >> MemorySegment.asByteBuffer, which creates a direct ByteBuffer with a
> >> controllable lifecycle. So using JNI would require FFM and using the
> >> full FFM code instead should make more sense.
> >
> > +1.
> >
> >> We will of course have to see how things turn out ...
> >
> > FFM is looking more and more like the way to go.
> >
> >> Another, less problematic, yet still annoying change will be
> >> https://openjdk.org/jeps/472 in Java 24+. Basically, the native access
> >> flag use will become mandatory. This is a bit annoying since it is not
> >> possible to add "--enable-native-access=ALL-UNNAMED" in the default
> >> command line without breaking on older Java.
> >
> > So we have issues when running older Tomcats that have to work with JREs
> > that don't have FFM - hence they need JNI.
> >
> > We have had issues like this before and have managed to hack around
> > them. Maybe it is time for slightly more robust solution. I was thinking
> > something like:
> >
> > - new class in bootstrap JAR with a main method that just returns the
> > current major java version as the exit code
>
> Could this be done without any custom code? I suppose running "java
> -version" and parsing the output using grep/sed/awk/Perl/whatever would
> be error-prone.
This does not look like it is super portable. So yes, having a utility
class in buildutils and then bootstrap could help clean things up.
> I suppose the performance difference between running "java -version" and
> "java GetMajorVersion" is negligible.
>
> > - the startup scripts call java with that class and store exit code in a
> > variable
> >
> > - we use that variable to select what to include when composing the main
> > command line to start Tomcat.
>
> +1 this should work
Yes, it would.
For my javac version in Tomcat 9, it is doing:
<exec executable="${java-ffm.home}/bin/javac"
outputproperty="javac25.version">
<arg value="-version" />
</exec>
This utility class could also cover parsing of the javac output maybe ...
Rémy
> -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
