RFR: 8348828: Windows dll loading now resolves symlinks [v8]

[Benjamin Peterson]

On Wed, 8 Oct 2025 01:57:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't see that this is a hotspot issue and you can't just unconditionally add a dot to all passed in names - that will surely break any code that expected the .DLL to be appended!

I'm not sure such code previously would have worked. As far as I can tell, `System.loadLibrary` would fail before reaching `os::dll_load` if the string passed into `System.loadLibrary` could not be resolved to an extant file by `NativeLibraries`.

(Okay, I suppose that if `mylib` and `mylib.dll` both exist, `System.loadLibrary("mylib")` would actually load `mylib.dll`. But that actually seems bad?)

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

This change doesn't affect the resolution of symlinks now, though.

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

liach's observation in https://github.com/openjdk/jdk/pull/24694#issuecomment-3377528055 that the JNI and `System.loadLibrary` should behave similarly likely means some hotspot change is needed.

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

I agree that the reproducer in the bug is not something you should do for itself; it is a small self-contained way to demonstrate the regression. I tried to expand on what the broken application actually does a few more places if that helps such as here: https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766.

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

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