RFR: 8348828: Windows dll loading now resolves symlinks

[Alan Bateman]

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`.

Are you the submitter of JDK-8348828? Asking because the configuration described seems very unusual and sounds like something that changed the JDK image so the DLLs from the JDK bin directory are moved to somewhere else and sym link put in place instead. I think we also need to understand if there is a bug in File::getCanonicalPath before change the usage.

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

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