Changes made outside VS Code (edit / delete of `.java`) are not picked up for Eclipse projects with linked source folders — stale errors for hours

[llgcode]

Environment

• OS: Windows 11 Enterprise 10.0.26100
• VS Code: 1.139.0 (2242ebbb54efeeb0129e08e919e7e8d43033cd83)
• vscode-java: 1.56.0 (win32-x64, embedded JRE), installed 2026-09-08 over 1.54.0
• Project JDK: JavaSE-21
• Plain Eclipse projects (.project / .classpath, no Maven/Gradle), about 100 of them

Summary

Since roughly the update to 1.56.0, jdt.ls no longer sees changes made to Java files outside VS Code
(for example by an AI coding agent or by git in a terminal). A method added to a class stays
"undefined" for hours, and a deleted file is still read by the builder, which then blocks the build of
every dependent project. Before the update, the same workflow was picked up without any action. We have
not confirmed the regression by downgrading.

Layout

The .project files live in their own folder, and each project's src is a linked folder
pointing to the sources elsewhere in the same VS Code workspace folder. Reduced to two projects:

c:/work/demo/                     <- folder opened in VS Code
├── core/src/demo/core/Greeter.java
├── app/src/demo/app/Main.java    <- uses Greeter
└── eclipse/
    ├── core/.project  .classpath
    └── app/.project   .classpath

<!-- eclipse/app/.project -->
<projectDescription>
  <name>app</name>
  <buildSpec><buildCommand><name>org.eclipse.jdt.core.javabuilder</name></buildCommand></buildSpec>
  <natures><nature>org.eclipse.jdt.core.javanature</nature></natures>
  <linkedResources>
    <link><name>src</name><type>2</type><location>c:/work/demo/app/src</location></link>
  </linkedResources>
</projectDescription>

<!-- eclipse/app/.classpath -->
<classpath>
  <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21"/>
  <classpathentry kind="src" path="/core"/>
  <classpathentry kind="src" path="src"/>
  <classpathentry kind="output" path="bin"/>
</classpath>

The linked source files are inside the workspace folder and match the basic watcher **/*.java.
The linked locations use a lowercase drive letter (c:/), while jdt.ls markers report the same
files as C:/….

Steps to reproduce

1. Open c:/work/demo and wait for the initial build to finish.
2. Outside VS Code, add a method getName() to core/src/demo/core/Greeter.java.
3. In Main.java (open in the editor), call new Greeter().getName().
4. Outside VS Code, delete another Java file from core/src.

Expected

jdt.ls receives workspace/didChangeWatchedFiles, refreshes the resources, and rebuilds incrementally.

Actual

Messages from jdt_ws/.metadata/.log (file and type names replaced by those of the example):

• The added method is still unknown 2.5 hours after the change:

  !MESSAGE Error occured while building workspace. Details:
   message: The method getName() is undefined for the type Greeter; resource: C:/work/demo/app/src/demo/app/Main.java
  

• A file deleted on disk is still in the resource tree 1.5 hours later:

  !ENTRY org.eclipse.jdt.core 4 969
  !MESSAGE File not found: C:\work\demo\core\src\demo\core\Deleted.java.
  org.eclipse.core.internal.resources.ResourceException(/core/src/demo/core/Deleted.java)[368]
  

• That deleted file then blocks the whole dependency chain:

  message: The project was not built since the source file /core/src/demo/core/Deleted.java could not be read
  message: The project cannot be built until its prerequisite core is built. Cleaning and building all projects is recommended
  

"Java: Force Java Compilation (Full)" does not recover: BuildWorkspaceHandler runs a CLEAN_BUILD
without refreshLocal, so it rebuilds the same stale tree.

Where we think it breaks (not verified)

• Client side: 1.56.0 moved to vscode-languageclient 10.1.0; the notifications may no longer be
  forwarded for the dynamically registered watchers.
• Server side: the notification arrives, but the file:///c%3A/... URI is not mapped to the linked
  resource (findFilesForLocationURI), possibly because of the drive-letter case.

We can provide a "java.trace.server": "verbose" trace showing whether workspace/didChangeWatchedFiles
arrives for the changed file.

Unrelated, same log

"java.format.settings.url": "file:./.vscode/formatter.xml" makes registerWatchers log an exception
at every start (it is caught, so only the formatter file goes unwatched):

java.lang.IllegalArgumentException: URI is not hierarchical
	at java.base/java.io.File.<init>(Unknown Source)
	at org.eclipse.jdt.ls.core.internal.managers.StandardProjectsManager.addWatcher(StandardProjectsManager.java:636)
	at org.eclipse.jdt.ls.core.internal.managers.StandardProjectsManager.registerWatchers(StandardProjectsManager.java:562)

[llgcode]

Closing: the cause was our java.format.settings.url value.

With "file:./.vscode/eclipse-java-code-style.xml", jdt.ls ignores every file change made outside VS Code. With the plain relative path ".vscode/eclipse-java-code-style.xml", changes are picked up again and the formatter profile is still applied.

For reference: in StandardProjectsManager.fileChanged(), getURIs() throws IllegalArgumentException: URI is not hierarchical on that opaque file: URI, so the change is dropped without being logged. A clearer error for that value would have saved us a lot of time.