RFR: 8348828: Windows dll loading now resolves symlinks

[Benjamin Peterson]

On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was 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 using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`.

Going back to the reproducer in my OP on JBS:

> mv .\jdk-24\bin\jimage.dll rando
> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
> \jdk-24\bin\javac 

During JVM startup, `NativeImageBuffer` will execute `System.loadLibrary("jimage")`, which will eventually make its way into `NativeLibraries.loadLibrary`. `NativeLibraries` will search the native library path and identitfy `.\jdk-24\bin\jimage.dll` as a file to load. The `getCanonicalPath()` invocation changed in this PR will be invoked to determine the final path to load. At this point, the path to load will be `$PWD\rando` due to symlink resolution. Entering the VM, `NativeLibraries.load` will eventually pass `$PWD\rando` to `LoadLibrary`. Since `.\rando` lacks a `.dll` extension on its face, `LoadLibrary` will add it, observe that `$PWD\rando.dll` doesn't exist and fail. This chain of events is avoided by presenting `LoadLibrary` with `jimage.dll` and letting the system do the symlink resolution as happened previously in JDK23.

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

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