<div dir="ltr">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.<br><br>For jtreg tests with native, the native code has normally been linked into shared libraries. <a href="https://openjdk.org/jeps/178">JEPS 178</a> 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 <a href="https://github.com/openjdk/leyden/tree/hermetic-java-runtime">leyden/tree/hermetic-java-runtime</a> 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.<div><br></div><div>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!</div><div><br></div><div>Best,</div><div>Jiangli<br><br></div></div>