On Thu, 16 Apr 2026 20:37:23 GMT, Benjamin Peterson <[email protected]> wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is >> called on the target library file before it is passed to the system library >> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve >> symlinks on Windows. This had unintended consequences for passing a symlink >> to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API >> inspects the file name passed to it and adds a `.dll` extension if the it is >> not already present. Thus, if `System.loadLibrary` was given a symlink to a >> file and that file didn't have a `.dll` extension, `LoadLibrary` try to load >> nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths `NativeLibraries`. This >> trailing dot inhibits `LoadLibrary`'s own appending behavior. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Benjamin Peterson has updated the pull request with a new target base due to > a merge or a rebase. The pull request now contains 20 commits: > > - append '.' to library names on Windows so that LoadLibrary doesn't mangle > them > - Merge branch 'master' into nativelibraries-fix > - update copyright years of test files > - Merge branch 'master' into nativelibraries-fix > - Merge branch 'master' into nativelibraries-fix > - add test showing loading symlinked libraries with various combinations > - revert dll_load fix > - Merge branch 'master' into nativelibraries-fix > - add cast > - use os::malloc > - ... and 10 more: https://git.openjdk.org/jdk/compare/10e23dd5...d42b58b4 I've reinstanted the "core-libs" solution, which is to append "." on Windows in `NativeLibraries`. The test demonstrates that the regression is fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-4264029179
