JDK-8348828 : Windows dll loading now resolves symlinks
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 24
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: generic
  • Submitted: 2025-01-24
  • Updated: 2025-05-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8003887 - File.getCanonicalFile() does not resolve symlinks on MS Windows
Description
A DESCRIPTION OF THE PROBLEM :
In JDK 23, it was possible to build up a Java home directory with symlinks. I.e., make functioning JDK directory where every file in the JDK tree was a symlink to somewhere else. This seems to have regressed on Windows in JDK 24 EA builds. Specifically, the JDK now fails to find critical native libraries on startup.

I suspect this was a downstream consequence of https://github.com/openjdk/jdk/commit/042053c3a82e9fbd4c6866efe872c1c92714e6e7

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Unpack the JDK 24 download zip file on a Windows machine. The JDK is now in a directory called "jdk-24".
Do some powershell commands:

> mv .\jdk-24\bin\jimage.dll rando
> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value 
> .\rando

Attempt to execute javac:

> .\jdk-24\bin\javac


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
javac prints its help message. This is what happens on JDK 23.
ACTUAL -
Error: Unable to load main class com.sun.tools.javac.Main in module jdk.compiler Caused by: java.lang.UnsatisfiedLinkError: .\rando: Can't find dependent libraries
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24694 Date: 2025-04-16 17:01:06 +0000
07-05-2025
Additional Information from submitter: ==================================== Would it be possible to replace the File.getCanonicalPath() in NativeLibraries.java with File.getAbsolutePath()? I tried this change, and it fixed my problem.
28-02-2025
File.getCanonicalFile should follow sym links. It seems however that unusual configuration in this bug report is an environment that is somehow dependent on not following sym links? I think one thing we need to double check is that the launcher and VM is correctly following sym links in all cases, just in case this is a case where sym links are followed in some cases, and not in others.
04-02-2025
As implied by the commit link in the description, this appears likely to be an unintended consequence of the fix for JDK-8003887. A solution for this would be, instead of File.getCanonicalFile, to use Path.toRealPath(LinkOption.NOFOLLOW_LINKS) [1]. [1] https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)
03-02-2025
The scenario is very strange but it suggests that there may be somewhere where the sym links are being followed correctly, but not in other cases, maybe in the java launcher or during early startup.
02-02-2025
Additional information received from submitter ======================================= The context is a distributed system for executing build tasks such as compilation and testing across machines. The system identifies and distributes files by the SHA-256 hash of their content. The files, named after their hashes, are stored on each machine in one central folder. To actually run a task, we set up a symlink tree of files that the task expects. Each symlink points to the appropriate file in the central storage directory. So, for example, to run a task that needs a JDK, part of the symlink tree will look like this: C:\jdk\bin\java -> C:\files\aaa333333 C:\jdk\bin\jimage.dll -> C:\files\badfff343677 C:\jdk\lib\modules -> C:\files\deadbeef232423 The symlink tree approach allows quickly setting up and tearing down workspaces for different tasks without expensive filesystem copying. This system has worked quite well on Linux and macOS. And it's worked on Windows until we started testing Java 24 EA.
28-01-2025
Observation on Windows 11 =========================== JDK 23.0.2 : Passed (javac prints the help message) JDK 24ea : Failed (Error: Unable to load main class com.sun.tools.javac.Main in module jdk.compiler Caused by: java.lang.UnsatisfiedLinkError:)
27-01-2025
Mail to submitter =================== This is regarding the JBS bug reported on ‘windows dll loading now resolves symlinks’. We were able to reproduce the issue. But in order to resolve this, our engineers would like to get a high level summary on what is being done i.e. any particular use case/expectation.
27-01-2025
This is a very strange bug report. Would it be possible to get a high level summary on what the submitter is doing?
26-01-2025