On Fri, 9 May 2025 09:10:21 GMT, Alan Bateman <al...@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
