<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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.</p>
<p>> 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. <br>
</p>
<p>Could you give some examples of the assumptions you're talking
about here?<br>
</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 1-2-2025 01:29, Jiangli Zhou wrote:<br>
</div>
<blockquote type="cite" cite="mid:CALrW1jwUbO9TZr3XZxsy5n-vJ+et_Zcg5MyiV6B9k_WMnUA_+w@mail.gmail.com">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</blockquote>
</body>
</html>