On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson <d...@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
