On Wed, 7 May 2025 19:05:17 GMT, Alan Bateman <al...@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`. > > Would it be possible to paste in here, or in the JBS issue, some examples of > the path provided to LoadLibrary with some commentary on the sym links > created on the file system. > You might be correct. We'll see what @AlanBateman and others have to say > about it. It's still puzzled as to why the DLLs have been moved from the JDK bin directory to some other location, and renamed so they don't have the ".dll" suffix. There most be some other product in the picture that we can't see. The quoted text from the Windows LoadLibrary documentation, where it appends the ".dll" suffix when not provided, is very useful as it helps us understand why it fails. As regards dropping the canonicalization then it would require thinking about the lock map used for mapping the library names to locks. It would need checking if it would break concurrent loading when using different names / file paths to the same DLL. There may be a route that involves adding a method to ClassLoaderHelper to post-process the path and the Windows version could add the "." when it doesn't have the ".dll" suffix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2863176924
