RFR: 8348828: Windows dll loading now resolves symlinks

[Benjamin Peterson]

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

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

Yes, the mystery product is my code. :) It makes a JDK image with a tree of symlinks to a data directory. The regular files in the data directory do not have file extensions.

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

I can see that removing the canonicalization could break the lock map. (Though I see the current deduplication and locking scheme doesn't handle hardlinks. Probably it would have to be keyed by `FileKey` to do that.)

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

I tried out this approach, and it solves my problem. I've now pushed the implementation.

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

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