RFR: 8348828: Windows dll loading now resolves symlinks

[Alan Bateman]

On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.
> 
> I'm 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.

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

The bug report is an unusual environment where the DLLs in the JDK bin directory are moved and renamed to some other location and without the .dll suffix, and sym links created in their place. That's a bit of distraction. A better starting point for discussion would be a test that exercises System.loadLibrary with the a library name that locates a DLL through a sym link to a final target that doesn't have the .dll suffix.  There's a matrix of configurations to test there. Same thing with System.load to see what works and doesn't work.

The discussion/proposal was originally to use the platform specific jdk.internal.load.ClassLoaderHelper as that gets used by the implementation of ClassLoader/NativeLibraries code to setup the path to the native library. I think we should stay away from JVM_LoadLibrary and os::dll_load for now, at least until we get come to some consensus on whether is this something that should be allowed (it may require input from security folks).

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

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