On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman <al...@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
