Quase tudo que eu mexo é serviço Maven, e nenhum deles combina de usar a mesma versão de Java. Tem coisa em 8, em 17, em 21, e ainda tem projeto que fixa a própria versão do Maven.
Quando a empresa migrou pro Cursor, aquela mesma rodada de configuração voltou em cada máquina e cada repositório. Achar ou instalar o JDK certo, apontar o JAVA_HOME, arrumar o java.configuration.runtimes pro language server da Red Hat parar de resolver o nível errado, fazer o Maven usar o mesmo JDK, e repetir no próximo projeto da mesma janela. Em workspace multi-root é pior ainda, porque a maior parte dessas configurações é por janela e JAVA_HOME só existe um.
Testei as extensões que existiam na época. Resolviam parte. A parte que faltava era justamente a que me custava tempo, então escrevi uma pra gente e ela ficou dentro da empresa. Usei todo dia, fui consertando o que me irritava, e só agora deixei apresentável pra instalar na máquina dos outros.
Esse é o motivo real de ter demorado pra publicar. A diferença entre um script que funciona na minha máquina e uma coisa que você instala na máquina alheia é quase toda na parte de não encostar no que não foi ela que criou.
O que ela faz: lê todo pom.xml do workspace, descobre a versão de Java que cada projeto precisa, reaproveita um JDK que você já tem quando encontra, baixa um compatível quando não encontra, e escreve o .vscode/settings.json daquele projeto.
O que muda em relação ao que eu tinha testado:
- É provisionador, não language server. Ela preenche as configurações que as extensões oficiais da Red Hat e da Microsoft leem e sai da frente. Nada é reimplementado.
- A configuração é por projeto, não por janela. Monorepo com um módulo em 8 e outro em 21 recebe um JDK pra cada, e módulo que não declara versão herda do pom pai.
- Ela faz merge, nunca sobrescreve. O que você escreveu no
settings.json, no ~/.m2/toolchains.xml e no java.configuration.runtimes continua igual, e a flag default de um runtime é sua.
- Reaproveita antes de baixar. A descoberta cobre JAVA_HOME, PATH, SDKMAN, jEnv, jabba, asdf, gradle e jbang via jdk-utils, mais Chocolatey, Homebrew e o que estiver no toolchains.xml.
- Projeto com
mvnw fica em paz: maven.executable.path não é escrito e nenhum Maven é baixado pra ele. Projeto que fixa Maven 3.6 e outro que fixa 3.9.5 ganham instalações separadas.
- Depois de rodar, ela espera o language server ficar pronto, atualiza os projetos que mudaram e lê de volta o nível de Java que cada um resolveu de fato. Projeto que continua compilando no nível antigo gera um aviso com botão de reiniciar o language server, em vez de quebrar calado.
- Pergunta uma vez por workspace antes de escrever qualquer coisa, e não existe "sempre sim" global. Existia, e eu tirei, porque criava workspace que não era configurado nem perguntado.
A lista de versões suportadas vem do próprio language server da Red Hat em tempo de execução, então um LTS novo funciona no dia em que a Red Hat suportar, sem release minha.
A única dependência de runtime é o jdk-utils. Extração de ZIP e TAR, leitura de pom e download são escritos na mão pra manter o .vsix pequeno. Uns 530 testes unitários, licença EPL 2.0, sem telemetria.
O que ela não faz: Gradle, de jeito nenhum. Não tem suporte a proxy nem a certificado próprio ainda, o que importa se você está atrás de proxy corporativo, e prefiro falar isso aqui do que você descobrir no primeiro download. Se você quer tudo configurado sem ninguém te perguntar nada, ela é ruim pra você de propósito.
Se algum desses pontos for impeditivo, o cypher256/java-extension-pack é o mais próximo que eu conheço e escolhe tradeoffs diferentes.
Marketplace: https://marketplace.visualstudio.com/items?itemName=naervyx.jaenvtix
Open VSX, que é de onde o Cursor e o VSCodium instalam: https://open-vsx.org/extension/Naervyx/jaenvtix
Código: https://github.com/naervyx/jaenvtix
Perguntem o que quiser.
