Jtreg tests with JNI native code on static JDK

[Jiangli Zhou]

With the recently enhancements in JDK mainline (thanks for all
contributions to the related work), it's able to build a static-jdk image
(support a static-jdk/bin/java launcher executable statically linked with
JDK/hotspot native), and able  to execute jtreg tests on the static-jdk
image. While the JDK mainline is reaching this milestone, I think it would
be good to start a conversation to seed the brainstorm on jtreg testing on
static-jdk image, specifically for tests with JNI natives.

For jtreg tests with native, the native code has normally been linked into
shared libraries. JEPS 178 <https://openjdk.org/jeps/178> enhanced JNI
specification to support statically linked native libraries. As a result,
we could build the jtreg test native code into static libraries and link
those with the static-jdk/bin/java launcher. An obvious alternative is to
continue building the jtreg test native code in shared libraries for
testing on static-jdk images. The alternative is feasible (the current
leyden/tree/hermetic-java-runtime
<https://github.com/openjdk/leyden/tree/hermetic-java-runtime> branch can
be used to demonstrate this capability). It's probably also a less
disruptive solution for running jtreg tests on static JDK using today's
existing testing framework/setup.

There are some pre-existing assumptions about dynamic loading and linking
native libraries in the tests (we have addressed and resolved many of those
in JDK and VM in JDK mainline already). For both approaches described in
above paragraph, we would need to remove these assumptions from the jtreg
tests regardless which approach is used for building/packaging the test
native code. Would be great to see this brief writeup brings in more
thoughts and discussions on the Jtreg testing strategy on static JDK.
Thanks!

Best,
Jiangli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250131/c275dce5/attachment.htm>