Better Java/JVM ecosystem awareness — framework conventions, LSP config, and build tool detection

[rameshreddy-adutla]

Describe the feature or problem you'd like to solve

Copilot CLI's documentation and intelligence is heavily TypeScript/JavaScript-oriented. The README's LSP section only shows TypeScript examples, with no guidance for Java — one of the most widely used enterprise languages. JVM developers using frameworks like Micronaut, Spring Boot, or Quarkus need the CLI to understand framework-specific conventions to be genuinely useful as an agentic coding assistant.

As a Java architect working with Micronaut microservices and Gradle multi-module builds, I'd like Copilot CLI to have first-class awareness of JVM project structures and framework conventions.

Proposed solution

1. Java LSP configuration example in README

The lsp-config.json section only shows TypeScript. Add a Java example using jdtls (Eclipse JDT Language Server), which is the standard Java LS used by VS Code and other editors:

{
  "lspServers": {
    "java": {
      "command": "jdtls",
      "args": ["-data", "/tmp/jdtls-workspace"],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

2. Build tool detection

Auto-detect the project's build system and use the correct wrapper/tool:

• ./gradlew / gradlew.bat → Gradle wrapper (preferred over system gradle)
• mvnw / mvnw.cmd → Maven wrapper (preferred over system mvn)
• build.gradle.kts / build.gradle → Gradle project
• pom.xml → Maven project

Currently, the agent may run gradle or mvn directly instead of the project-local wrappers, which can use the wrong version or miss project-specific configuration.

3. Framework convention awareness

JVM frameworks are heavily convention and annotation-driven. The CLI should understand:

Micronaut:

• @Singleton, @Controller, @Client, @Factory — DI and HTTP patterns
• application.yml / application-{env}.yml — environment-specific config
• @MicronautTest — test lifecycle

Spring Boot:

• @RestController, @Service, @Repository, @Configuration — layered architecture
• application.properties / application-{profile}.yml — profile-based config
• @SpringBootTest, @WebMvcTest — slice testing

Common JVM patterns:

• src/main/java / src/test/java — standard Maven/Gradle layout
• src/main/resources — config and static resources
• Package naming conventions mapping to directory structure

4. Multi-module project navigation

Enterprise Java projects are almost always multi-module. The CLI should:

• Parse settings.gradle.kts / settings.gradle / parent pom.xml to understand module boundaries
• Run module-scoped commands: ./gradlew :module-name:test instead of ./gradlew test
• Navigate between API and implementation modules

Example prompts or workflows

1. "Add a new REST endpoint for /api/v1/rewards with request validation" → generates correct Micronaut/Spring-specific controller code with framework annotations, not generic Java
2. "Run the tests for the linking-service module" → executes ./gradlew :linking-service:test (not gradle test or ./gradlew test)
3. "Show me all the HTTP clients in this project" → finds @Client annotated interfaces (Micronaut) or RestTemplate/WebClient usages (Spring)
4. "Add a new configuration property for the retry timeout" → adds to the correct application.yml with framework-appropriate syntax
5. "Create an integration test for the account service" → uses @MicronautTest or @SpringBootTest depending on the framework detected

Additional context

• Java consistently ranks in the top 3 languages on GitHub and is the dominant language in enterprise development
• The JVM ecosystem (Java, Kotlin, Scala) shares build tools (Gradle, Maven) and project conventions
• VS Code Copilot Chat already has some Java awareness via the Java extension pack — parity in the CLI would benefit the large population of terminal-first Java developers
• Kotlin DSL (build.gradle.kts) is now the default for new Gradle projects and should be understood alongside Groovy DSL

[wenytang-ms]

@rameshreddy-adutla
I'm from vscode java team, while I config the java lsp and it works, for examples
in 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",
        "-noverify",
        "-Xmx1G",
        "--add-modules=ALL-SYSTEM",
        "--add-opens", "java.base/java.util=ALL-UNNAMED",
        "--add-opens", "java.base/java.lang=ALL-UNNAMED",
        "-jar", "/home/user/.vscode-server/extensions/redhat.java-1.54.2026030508-linux-x64/server/plugins/org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar",
        "-configuration", "/home/user/.vscode-server/extensions/redhat.java-1.54.2026030508-linux-x64/server/config_linux",
        "-data", "/home/user/.copilot/jdtls-workspace"
      ],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

in .github/lsp.json

{
  "lspServers": {
    "java": {
      "command": "/home/users/.vscode-server/extensions/redhat.java-1.54.2026030508-linux-x64/jre/21.0.10-linux-x86_64/bin/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",
        "--add-modules=ALL-SYSTEM",
        "--add-opens",
        "java.base/java.util=ALL-UNNAMED",
        "--add-opens",
        "java.base/java.lang=ALL-UNNAMED",
        "-jar",
        "/home/user/.vscode-server/extensions/redhat.java-1.54.2026030508-linux-x64/server/plugins/org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar",
        "-configuration",
        "/home/user/.vscode-server/extensions/redhat.java-1.54.2026030508-linux-x64/server/config_linux",
        "-data",
        "/home/user/javarepo/java-debug/.jdtls-workspace"
      ],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

[wenytang-ms]

However, for large Java projects, JDTLS parsing may take a noticeable amount of time. While the CLI currently shares the same underlying mechanism as the VS Code integration, would it be possible to expose a signal or listener to indicate when the LSP is fully ready?
In addition, even with the Java LSP enabled, models such as Opus 4.6 still tend to rely on built-in tools like grep and `search unless they are explicitly guided to use LSP tools. This behavior mirrors what we see in VS Code and indicates an area that still needs improvement.

[jdubois]

@wenytang-ms you can simplify the lsp-config.json as most of it is already in the Python wrapper, then you can add a few options to make it faster. Here is my configuration:

{
  "lspServers": {
    "java": {
      "command": "jdtls",
      "args": [
        "--jvm-arg=-Xmx4G",
        "--jvm-arg=-Dlog.level=WARN",
        "--jvm-arg=-XX:+UseStringDeduplication",
        "-data", "/Users/juliendubois/.cache/jdtls-workspace"
      ],
      "fileExtensions": {
        ".java": "java"
      }
    }
  }
}

-> if you have a good place to document this, please point me to it, I'll happily share this in an official documentation.