On Fri, 9 May 2025 17:42:14 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 after canonicalization >> on Windows. This trailing dot inhibits `LoadLibrary`'s own appending >> behavior. > > Benjamin Peterson has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - switch platform helper to be mapToNativeLibraryName > - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix > - fix spelling > - new approach: append . to file name on Windows > - 8348828: Windows dll loading now resolves symlinks Thanks for prompting for attention on the mailing list. I just wonder if it would be better for us to handle this in `os::dll_load` in `os_windows.cpp` - this seems a better way to handle generic platform-specific peculiarities. This approach also means JNI and all other users would be updated too, but I don't see why JNI would handle this differently from class loader APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3377528055
