A Databricks liberou o código-aberto do Metals v2, um servidor de linguagem para Java e Scala que indexa um milhão de linhas de código por segundo e se torna utilizável em 20 segundos em um monorepo de 26 milhões de linhas. O lançamento, realizado com VirtusLab e Cursor, é distribuído no Cursor, VS Code e Neovim hoje.
A aposta central: sincronização IDE dependente de build é um gargalo. Servidores de linguagem JVM tradicionais bloqueiam na sincronização da ferramenta de build antes de você conseguir navegar qualquer coisa—um processo que pode levar minutos em bases de código grandes e falha sob a rápida aleatoriedade de arquivos que fluxos de trabalho com agentes produzem. Metals v2 contorna isso indexando arquivos de fonte diretamente. Para Java, usa Turbine (compilador de cabeçalho do Google) para extrair informações de tipo sem compilação completa. Para Scala, usa a opção `-sourcepath` do compilador para resolver símbolos da fonte. A navegação é instantânea após o índice inicial; resolução de dependências e teste/debug permanecem opcionais via servidor BSP.
A Databricks construiu isso porque seu monorepo—26 milhões de linhas de Scala e Java—não tinha um caminho credível através de servidores de linguagem JVM existentes. IntelliJ era o único editor que conseguia lidar com isso. Em maio de 2025, a Databricks padronizou no Cursor para trabalho não-JVM, mas navegação JVM no monorepo era o bloqueador. A empresa estendeu Metals internamente, então trabalhou com VirtusLab e Cursor para enviar as mudanças upstream.
As métricas de adoção são definitivas. Depois que Metals v2 foi lançado no Cursor em outubro de 2025, a participação do Cursor em aberturas de arquivos Scala e Java subiu de 40% para 78%. Em julho de 2026, 92% dos usuários IDE ativos semanais na Databricks usam Cursor, versus 12% para IntelliJ. Entre usuários de IDE único, 2.400 executam Cursor e 120 usam IntelliJ. A Databricks não renovou a maioria de suas licenças IntelliJ este ano.
A adoção do Cursor tinha estagnado na Databricks em setembro de 2025—a lacuna Scala/Java era o freio. Uma vez que Metals v2 removeu essa restrição, o crescimento retomou. O time enquadra isso como um flywheel IDE: baseline compartilhada concentra investimento de plataforma, melhora ferramentas, reforça adoção. Esse flywheel estagna se o servidor de linguagem não consegue lidar com o monorepo.
Stripe está executando um lançamento paralelo. Mahib Hosain, da equipe Developer Platform da Stripe, confirmou que o servidor funciona bem em sua base de código Java—embora o lançamento tenha menos de um mês. O site do Metals v2 confirma que o suporte de ação de código Java é limitado a sugestões de import; refatorações (extract method, inline variable, move class) ainda não foram implementadas. Integração Bazel requer configuração. Teste e debug requerem um servidor BSP. Estas são lacunas reais para equipes que dependem da amplitude de refatoração do IntelliJ.
Metals v1.6.6 já enviou um servidor MCP que permite que agentes AI compilem código, executem testes e inspecionem símbolos independentemente. Metals v2 usa o mesmo banco de dados semântico e o torna rápido o suficiente para o ciclo de escrita com agentes, não apenas navegação humana. A Databricks enquadra essa mudança claramente: "agentes escrevem a maioria do código agora," então orientação confiável da base de código importa mais que amplitude de autocompletar. Essa reordenação de prioridades de recurso LSP é o que v2 foi projetado para fazer.
VirtusLab lidera o desenvolvimento contínuo. Para equipes executando grandes monorepos Java ou Scala e avaliando Cursor ou VS Code como uma substituição IntelliJ, Metals v2 é o primeiro caminho credível—com a ressalva de que suporte Bazel e refatoração completa permanecem em progresso.