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