LSP Java (jdtls) on Windows: position-based ops return "No language server available" while workspaceSymbol works

[wagnergsantos]

Environment:

• Copilot CLI: 1.0.64
• OS: Windows 11
• Java: OpenJDK Temurin 21.0.9
• LSP server: Eclipse JDT LS (jdtls), launcher org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar
• Project: Spring Boot 3 / Java 17 Maven (medium size)

Config (~/.copilot/lsp-config.json):

{
"lspServers": {
"java": {
"command": "java",
"args": [
"-Declipse.application=org.eclipse.jdt.ls.core.id1",
"-Dosgi.bundles.defaultStartLevel=4",
"-Declipse.product=org.eclipse.jdt.ls.core.product",
"-Dlog.level=ALL",
"-Xmx1G",
"-jar", "C:\tools\jdtls\plugins\org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar",
"-configuration", "C:\tools\jdtls\config_win",
"-data", "C:\tools\jdtls\workspace"
],
"fileExtensions": { "java": "java" },
"initializationTimeoutMs": 300000,
"warmupTimeoutMs": 300000,
"requestTimeoutMs": 120000,
"spawnTimeoutMs": 60000
}
}
}

What works:

• /lsp test java succeeds; jdtls process spawns and stays alive (~1 GB RSS).
• lsp workspaceSymbol returns correct results with package/line/column after initial indexing (~3 min on first call).

What fails:
All position-based and file-based LSP operations return "No language server available for file" even though the server is healthy and workspaceSymbol works in the same session:

• lsp documentSymbol on a .java file in the project → "No language server available"
• lsp goToDefinition (line/character on a known symbol) → "No language server available"
• lsp findReferences → same
• lsp hover → same
• lsp goToImplementation → same

Tried both Windows paths (C:...\File.java) and POSIX-style (C:/.../File.java) — same result. The file definitely exists and is inside the project root.

Logs (relevant excerpts from ~/.copilot/logs/process-*.log):

[ERROR] LSP java server for C:...\gpron-service: workspaceSymbols failed: Request 'workspace/symbol' timed out after 90000ms.

(Resolved after increasing requestTimeoutMs; workspaceSymbol then succeeded.)

Subsequent file-based operations log no jdtls error — the bridge seems to reject the request before it reaches the server.

Suspected cause:

• Possible URI canonicalization mismatch on Windows (file:///c:/... vs file:///C:/...)
• Possible missing textDocument/didOpen notification before position-based requests (jdtls requires the document to be opened first)

Expected: Position-based LSP ops should work consistently with workspaceSymbol once jdtls is initialized.

Workaround: Currently relying on workspaceSymbol + grep for code navigation in Java projects on Windows.