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

[David Holmes]

On Tue, 7 Oct 2025 20:54:08 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 in Windows' `os::dll_load`. 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:
> 
>   add cast

I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended!

As @AlanBateman has noted there are semantic question to address here. Library loading is tied to classloaders and the use of symlinks allows the same library to be loaded by different names in different classloaders - which could potentially wreak havoc I think if we execute the onLoad hooks multiple times.

I would like to see core-libs folk decide exactly what should happen for these different cases, and then figure out where is the best place to make that happen.

But initial view is that you should not be renaming the DLLs to not have a .dll extension - that just seems to be a self-inflicted wound.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24694#pullrequestreview-3312513111