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