On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson <d...@openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is 
>> called on the target library file before it is passed to the system library 
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve 
>> symlinks on Windows. This had unintended consequences for passing a symlink 
>> to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API 
>> inspects the file name passed to it and adds a `.dll` extension if the it is 
>> not already present. Thus, if `System.loadLibrary` was given a symlink to a 
>> file and that file didn't have a `.dll` extension, `LoadLibrary` try to load 
>> nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths after canonicalization 
>> on Windows. This trailing dot inhibits `LoadLibrary`'s own appending 
>> behavior.
>
> Benjamin Peterson has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   fix spelling

I built the JDK with the diff in 70e943c applied on Windows 11 and verified 
that it resolves the scenario presented in the issue description, namely that 
`jimage.dll` can be moved elsewhere, in this case `C:\Users\bpb\rando`, and a 
link created from `jimage.dll` to `rando` and with this config `java` and 
`jshell` can be run.

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

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

Reply via email to