Jtreg tests with JNI native code on static JDK

[Jorn Vernee]

Statically linking native test libraries seems strange to me. If we 
think of a test case as a user of the Java runtime, it should not matter 
whether the Java runtime is a hermetic image or not, and dynamic linking 
of native libraries should continue to work as before, I think. Unless 
I'm misunderstanding the goal of hermetic images, it is still possible 
to dynamically load e.g. jar files with a hermetic Java image, right? 
Those jar files could contain/depend on dynamic native libraries, so I 
think either way those need to be supported.

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

Could you give some examples of the assumptions you're talking about here?

Jorn

On 1-2-2025 01:29, Jiangli Zhou wrote:
> 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/20250203/f5f40d25/attachment-0001.htm>