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

[Benjamin Peterson]

On Fri, 9 May 2025 09:10:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is this documented in the Microsoft document for LoadLibrary? We don't want to rely on undocumented behavior as it could break at any time.

[LoadLibraryEx` documentation](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa) states:

To prevent the function from appending ".DLL" to the module name, include a trailing point character (.) in the module name string.

which isn't incompatible with not adding `.dll` when the extension is already present.

Practically speaking, I imagine the behavior of a common operating system API available since at least Windows XP is completly ossified.

> 
> For the prototype, I think you can replace nativeLoaderFileNameSuffix() with mapToNativeLibraryName(String) so that other platforms can "return this". This would give the flexibility to prefix or do other mangling.

I've changed the implementation to do this.

> 
> That said, I'm not so sure that we should changing the JDK to work in this unusual environment. Are you able to name the product that is move-renaming the DLLs and replacing them with sym links? Just trying to get some sense as to whether this is something that many people might run into it.

I understand the narrow reproducer in the bug is weird, but it was isolated from a generically useful system. As I explained in https://bugs.openjdk.org/browse/JDK-8348828?focusedId=14744766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14744766, this arises in a generic system my company offers for executing tasks in distributed fashion across many machines. We don't have any particular interest in DLLs or even JDK installations; we simply create a symlinks for all data required by tasks that our system is asked to execute.

This system worked fine with JDKS through Java 23 and all previous versions we've tried.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24694#discussion_r2082174367