Consider adding Java to `lsp.json`

[edburns]

The practice of moving copilot-sdk-java to copilot-sdk revealed that lsp.json does not currently have Java support.

Preliminary research revealed that adding jdtls may be a solution, but more research must be done before committing to this approach.

This work item tracks this matter.

Here is some state.

Assessment: Add Java LSP to lsp.json

Current State

lsp.json configures language servers for the Copilot coding agent (the cloud-based autonomous agent that works in GitHub Actions). It currently provides code intelligence for two languages:

• C# — via dotnet tool run roslyn-language-server (installed as a .NET tool, scoped to dotnet)
• Go — via gopls serve (available after setup-go, scoped to go)

There is no Java entry. This has not been done.

What does it give the coding agent?

When a language server is configured, the Copilot coding agent gets IDE-quality code intelligence (go-to-definition, find-references, diagnostics, rename) while working autonomously. Without it, the agent relies on text search and heuristics for Java code, which is less reliable for a strongly-typed language with deep class hierarchies.

Feasibility Concern: jdtls installation

Unlike gopls (single binary, already on PATH after setup-go) or Roslyn (installable via dotnet tool), Eclipse JDT Language Server (jdtls) requires:

1. Downloading a release archive (~70MB) from the Eclipse downloads mirror
2. Extracting it to a known location
3. Invoking it with a specific launcher jar path and a configuration directory
4. Providing a -data workspace path

This makes it harder to configure than the other two, but not impossible.

Plan

Option A: Install jdtls in copilot-setup-steps.yml and add to lsp.json (recommended)

1. Add a step to copilot-setup-steps.yml that downloads and extracts jdtls to a known path (e.g., $HOME/jdtls):

   - name: Install Eclipse JDT Language Server
     run: |
       JDTLS_VERSION="1.44.0"
       JDTLS_TIMESTAMP="202501301718"
       curl -fsSL "https://www.eclipse.org/downloads/download.php?file=/jdtls/milestones/${JDTLS_VERSION}/jdt-language-server-${JDTLS_VERSION}-${JDTLS_TIMESTAMP}.tar.gz&r=1" \
         -o /tmp/jdtls.tar.gz
       mkdir -p "$HOME/jdtls"
       tar -xzf /tmp/jdtls.tar.gz -C "$HOME/jdtls"
       rm /tmp/jdtls.tar.gz

2. Create a wrapper script at .github/scripts/jdtls-wrapper.sh that launches jdtls in stdio mode:

   #!/bin/bash
   exec java \
     -Declipse.application=org.eclipse.jdt.ls.core.id1 \
     -Dosgi.bundles.defaultStartLevel=4 \
     -Declipse.product=org.eclipse.jdt.ls.core.product \
     -Dlog.level=ALL \
     -noverify \
     --add-modules=ALL-SYSTEM \
     --add-opens java.base/java.util=ALL-UNNAMED \
     --add-opens java.base/java.lang=ALL-UNNAMED \
     -jar "$HOME/jdtls/plugins/org.eclipse.equinox.launcher_"*.jar \
     -configuration "$HOME/jdtls/config_linux" \
     -data "$HOME/jdtls-workspace"

3. Update lsp.json to add a Java entry:

   "java": {
     "command": "bash",
     "args": [".github/scripts/jdtls-wrapper.sh"],
     "fileExtensions": {
       ".java": "java"
     },
     "rootUri": "java"
   }

Option B: Skip this (keep it optional/deferred)

The coding agent already works on Java code in this repo without an LSP — it uses mvn verify for compilation feedback and the java-coding-skill SKILL.md for guidance. The agent's productivity without an LSP is "good enough" for the current volume of Java agent work. This could be deferred until the feature is better documented or until a simpler jdtls installation method exists (e.g., a GitHub Action or a single-binary distribution).

Recommendation

Go with Option B (defer) for now, for these reasons:

1. The lsp.json feature itself is not publicly documented — the schema, behavior, and supported options are not well-specified.
2. jdtls installation is fragile (version pinning, platform-specific config directory: config_linux vs config_mac vs config_win, launcher jar glob matching).
3. The agent runner is Ubuntu-only for Copilot cloud agent, so config_linux works, but this adds a maintenance burden for version updates.
4. The plan item was marked "(optional)" in the migration plan for exactly these reasons.
5. The coding agent already successfully builds and tests Java via mvn verify — the LSP would provide incremental improvement, not a critical fix.

If you want to proceed anyway

The implementation is straightforward — the three changes above (setup step, wrapper script, lsp.json entry). The main risk is jdtls version rot and the fact that jdtls takes 10-30 seconds to initialize a Maven project, which may slow down the agent's startup. I'd suggest opening a separate low-priority issue to track this and revisit when GitHub documents the lsp.json schema officially.

---