Databricks ha liberado bajo código abierto Metals v2, un servidor de lenguaje para Java y Scala que indexa un millón de líneas de código por segundo y se vuelve utilizable en 20 segundos en un monorepo de 26 millones de líneas. El lanzamiento, realizado con VirtusLab y Cursor, se distribuye en Cursor, VS Code y Neovim hoy.

La apuesta central: la sincronización IDE dependiente de la compilación es un cuello de botella. Los servidores de lenguaje JVM tradicionales se bloquean en la sincronización de herramientas de compilación antes de que puedas navegar nada—un proceso que puede tomar minutos en bases de código grandes y falla bajo la rápida rotación de archivos que producen los flujos de trabajo con agentes. Metals v2 evita esto indexando archivos fuente directamente. Para Java, utiliza Turbine (compilador de encabezado de Google) para extraer información de tipos sin compilación completa. Para Scala, utiliza la opción `-sourcepath` del compilador para resolver símbolos desde la fuente. La navegación es instantánea después del índice inicial; la resolución de dependencias y prueba/depuración permanecen opcionales a través del servidor BSP.

Databricks construyó esto porque su monorepo—26 millones de líneas de Scala y Java—no tenía una ruta creíble a través de servidores de lenguaje JVM existentes. IntelliJ era el único editor que podía manejarlo. En mayo de 2025, Databricks estandarizó en Cursor para trabajo no JVM, pero la navegación JVM en el monorepo era el bloqueador. La empresa extendió Metals internamente, luego trabajó con VirtusLab y Cursor para llevar los cambios upstream.

Las métricas de adopción son definitivas. Después de que Metals v2 se lanzó en Cursor en octubre de 2025, la participación de Cursor en aperturas de archivos Scala y Java aumentó del 40% al 78%. En julio de 2026, el 92% de los usuarios IDE activos semanales en Databricks usan Cursor, versus 12% para IntelliJ. Entre usuarios de IDE único, 2.400 ejecutan Cursor y 120 usan IntelliJ. Databricks no renovó la mayoría de sus licencias de IntelliJ este año.

La adopción de Cursor se había estancado en Databricks en septiembre de 2025—la brecha Scala/Java era el freno. Una vez que Metals v2 eliminó esa restricción, el crecimiento se reanudó. El equipo lo plantea como una rueda volante IDE: la línea base compartida concentra la inversión en plataforma, mejora las herramientas, refuerza la adopción. Esa rueda volante se estanca si el servidor de lenguaje no puede manejar el monorepo.

Stripe está ejecutando un lanzamiento paralelo. Mahib Hosain, del equipo Developer Platform de Stripe, confirmó que el servidor funciona bien en su base de código Java—aunque el lanzamiento tiene menos de un mes. El sitio web de Metals v2 confirma que el soporte de acción de código Java se limita a sugerencias de importación; las refactorizaciones (extract method, inline variable, move class) aún no se han implementado. La integración de Bazel requiere configuración. Las pruebas y depuración requieren un servidor BSP. Estas son brechas reales para equipos que dependen del alcance de refactorización de IntelliJ.

Metals v1.6.6 ya envió un servidor MCP que permite que los agentes de IA compilen código, ejecuten pruebas e inspeccionen símbolos de forma independiente. Metals v2 utiliza la misma base de datos semántica y la hace lo suficientemente rápida para el ciclo de escritura con agentes, no solo para la navegación humana. Databricks plantea este cambio claramente: "los agentes escriben la mayoría del código ahora," por lo que una orientación confiable de la base de código importa más que la amplitud del autocompletado. Esa reordenación de prioridades de características LSP es para lo que v2 fue diseñado.

VirtusLab lidera el desarrollo continuo. Para equipos que ejecutan grandes monorepos Java o Scala y evalúan Cursor o VS Code como un reemplazo de IntelliJ, Metals v2 es el primer camino creíble—con la salvedad de que el soporte de Bazel y la refactorización completa permanecen en progreso.