<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <br>

    <br>

    <div class="moz-cite-prefix">On 07/10/2025 16:15, Benjamin Peterson

      wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:CAEmfU+ub+Y4_7QaC+r5fzgHXz_AzS6XLgBbYktJ4V4UNRcbiiw@mail.gmail.com">

      <pre wrap="" class="moz-quote-pre">I've had a PR for the native library loading code up for a months that

I'd appreciate any review on:

<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/24694">https://github.com/openjdk/jdk/pull/24694</a>

To summarize the issue and proposed fix: Before OpenJDK 24,

System.loadLibrary on Windows passed symbolic links unresolved to the

underlying LoadLibrary function. JDK-8003887 caused symbolic links to

be resolved by Java before the system LoadLibrary function.

Unfortunately, LoadLibrary is clever and may mangle the filename

passed to it, which means passing a symlink may not have the same

behavior as presenting the fully resolved path. I propose to fix this

problem in the PR by disabling LoadLibrary's clever mangling behavior.

</pre>

    </blockquote>

    The reason this didn't come to a conclusion is because this isn't

    really a JDK bug, instead it's a about a strange environment where

    some "mystery product" has moved the DLLs out the JDK run-time image

    directory and put them somewhere without the .dll suffix. The JDK

    expects the DLLs to be in the bin directory and named ".dll".  So

    it's really a question as to whether the JDK should accept a change

    to allow this strange setup.<br>

    <br>

    -Alan<br>

  </body>

</html>