RFR: 8348828: Windows dll loading now resolves symlinks
Benjamin Peterson
duke at openjdk.org
Wed Jun 11 16:08:30 UTC 2025
On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> Would it be possible to paste in here, or in the JBS issue, some examples of the path provided to LoadLibrary with some commentary on the sym links created on the file system.
>
>> 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.
>
> 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. 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.
@AlanBateman any further feedback here?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-2963394413
More information about the core-libs-dev
mailing list