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

[Brian Burkhalter]

On Thu, 8 May 2025 17:43:31 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 incrementally with one additional commit since the last revision:
> 
>   new approach: append . to file name on Windows

src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java line 110:

> 108:      * Add a dot to the end of the library file name ultimately passed to
> 109:      * <code>LoadLibrary</code>. This prevents <code>LoadLibrary</code> from
> 110:      * automatically infering a .DLL extension.

`infering` -> `inferring`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2080181799