RFR: 8348828: Windows dll loading now resolves symlinks [v4]

[Benjamin Peterson]

On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson <duke at openjdk.org> 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

Any thoughts on the approach we landed on now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3053827761