Projects containing windows symlink directories are not recognized, nothing works

Environment

• Operating System: Windows 10
• JDK version: OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12
• Visual Studio Code version: 1.63.2
• Java extension version: Language Support for Java(TM) by Red Hat v1.2.0

Steps To Reproduce

1. Install Extension Pack for Java v0.20.0 (including the Language Support for Java(TM) by Red Hat v1.2.0)
2. Try do anything, open existing project, code Java in VS Code…

Current Result

Hardly anything works.

Expected Result

Actually anything.

Additional Informations

Logs: https://gist.github.com/AgainPsychoX/1c8d75f00fd53282fd6fafd7becf633c

Reoccurring thing seems to be:

java.lang.reflect.InaccessibleObjectException: Unable to make boolean sun.nio.fs.WindowsFileAttributes.isDirectoryLink() accessible: module java.base does not "opens sun.nio.fs" to unnamed module @57022ddd
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
	at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
	at org.eclipse.core.internal.filesystem.local.nio.DosHandler.isDirectoryLink(DosHandler.java:80)
	at org.eclipse.core.internal.filesystem.local.nio.DosHandler.fetchFileInfo(DosHandler.java:61)
	at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.fetchFileInfo(LocalFileNativesManager.java:65)
	at org.eclipse.core.internal.filesystem.local.LocalFile.fetchInfo(LocalFile.java:161)
	at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:260)
	at org.eclipse.core.internal.utils.FileUtil.realPath(FileUtil.java:129)
	at org.eclipse.core.internal.utils.FileUtil.realURI(FileUtil.java:184)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.setLocation(FileSystemResourceManager.java:1051)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.getStoreRoot(FileSystemResourceManager.java:578)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.locationURIFor(FileSystemResourceManager.java:813)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocationNonCanonical(FileSystemResourceManager.java:82)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocation(FileSystemResourceManager.java:70)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.allResourcesFor(FileSystemResourceManager.java:229)
	at org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(WorkspaceRoot.java:97)
	at org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(WorkspaceRoot.java:90)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.findResource(JDTUtils.java:1037)
	at org.eclipse.jdt.ls.core.internal.JDTUtils.resolveCompilationUnit(JDTUtils.java:184)
	at com.microsoft.jdtls.ext.core.PackageCommand.resolvePath(PackageCommand.java:127)
	at com.microsoft.jdtls.ext.core.CommandHandler.executeCommand(CommandHandler.java:33)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:215)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:205)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:507)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:75)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

[testforstephen]

@AgainPsychoX Could you try to append "--add-opens=java.base/sun.nio.fs=ALL-UNNAMED" to the existing VS Code setting "java.jdt.ls.vmargs"?

e.g. change it to the following value.

"java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m --add-opens=java.base/sun.nio.fs=ALL-UNNAMED"

[testforstephen]

@AgainPsychoX, thanks for your verification.

Yes, it’s a bug that we have to fix.

The reason is that your workspace contains symbolic links, and VS Code Java extension uses some JDK API sun.nio.fs.WindowsFileAttributes.isDirectoryLink() on Windows to check if it is a symbolic directory. This API is marked as an internal API starting with JDK 16, see JEP 396: Strongly Encapsulate JDK Internals by Default of JDK 16 Release Notes.

Using internal APIs will throw illegal access by default when running on JDK 16 and above. The solution is to avoid using JDK internal APIs, or use --add-opens command line option to permit access.

On the other hand, Java extension 1.2.0 embeds a minimal JRE 17 runtime to launch Java extension, that’s why it fails recently. In short term, we could use the JVM args "--add-opens=java.base/sun.nio.fs=ALL-UNNAMED" to explicitly permit access. In long term, we need to fix the upstream JDT code to avoid this internal API.