Better Java/JVM ecosystem awareness — framework conventions, LSP config, and build tool detection
- Dominant language
- Shell
- Stars
- 11.2k
- Forks
- 1.9k
- Avg merge
- 14h 16m
- Merged PRs (30d)
- 6
Description
## 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:
```json
{
"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
Contributor guide
Assessment
This issue has not been assessed yet.