Databricks has open-sourced Metals v2, a language server for Java and Scala that indexes one million lines of code per second and becomes usable in 20 seconds on a 26-million-line monorepo. The release, done with VirtusLab and Cursor, ships in Cursor, VS Code, and Neovim today.
The core bet: build-dependent IDE sync is a bottleneck. Traditional JVM language servers block on build-tool synchronization before you can navigate anything—a process that can take minutes on large codebases and fails under the rapid file churn agentic workflows produce. Metals v2 sidesteps this by indexing source files directly. For Java, it uses Turbine (Google's header compiler) to extract type info without full compilation. For Scala, it uses the compiler's `-sourcepath` option to resolve symbols from source. Navigation is instant after the initial index; dependency resolution and test/debug remain optional via BSP server.
Databricks built this because their monorepo—26 million lines of Scala and Java—had no credible path through existing JVM language servers. IntelliJ was the only editor that could handle it. In May 2025, Databricks standardized on Cursor for non-JVM work, but JVM navigation on the monorepo was the blocker. The company extended Metals internally, then worked with VirtusLab and Cursor to upstream the changes.
The adoption metrics are definitive. After Metals v2 shipped in Cursor in October 2025, Cursor's share of Scala and Java file opens rose from 40% to 78%. By July 2026, 92% of weekly active IDE users at Databricks use Cursor, versus 12% for IntelliJ. Among single-IDE users, 2,400 run Cursor and 120 use IntelliJ. Databricks did not renew the majority of its IntelliJ seats this year.
Cursor adoption had stalled at Databricks by September 2025—the Scala/Java gap was the brake. Once Metals v2 cleared that constraint, growth resumed. The team frames this as an IDE flywheel: shared baseline concentrates platform investment, improves tooling, reinforces adoption. That flywheel stalls if the language server can't handle the monorepo.
Stripe is running a parallel rollout. Mahib Hosain, from Stripe's Developer Platform team, confirmed the server works well in their Java codebase—though the rollout is less than a month old. The Metals v2 website confirms that Java code action support is limited to import suggestions; refactorings (extract method, inline variable, move class) are not yet implemented. Bazel integration requires setup. Test and debug require a BSP server. These are real gaps for teams relying on IntelliJ's refactoring breadth.
| Feature / Capability | Metals v2 | IntelliJ |
|---|---|---|
| Symbol navigation | ✓ Instant after initial index | ✓ Full |
| Java type info (no full compile) | ✓ via Turbine header compiler | ✗ Requires full compilation |
| Scala symbol resolution from source | ✓ via -sourcepath flag | ✓ Full |
| Java code actions | Import suggestions only | ✓ Full |
| Refactoring (extract method, inline var, move class) | ✗ Not yet implemented | ✓ Full |
| Bazel integration | Requires manual setup | ✓ Built-in |
| Test & debug | Requires BSP server (optional) | ✓ Built-in |
| MCP server (AI agent compile/test/inspect) | ✓ Since Metals v1.6.6 | ✗ |
| Indexing speed | 1M lines/sec | Build-tool-dependent |
| Usability on 26M-line monorepo | ~20 seconds | Minutes (build sync required) |
| Editors supported | Cursor, VS Code, Neovim | IntelliJ only |
Metals v1.6.6 already shipped an MCP server that lets AI agents compile code, run tests, and inspect symbols independently. Metals v2 uses that same semantic database and makes it fast enough for the agentic write-cycle, not just human navigation. Databricks frames this shift plainly: "agents write most of the code now," so reliable codebase orientation matters more than autocomplete breadth. That reordering of LSP feature priorities is what v2 is designed around.
VirtusLab leads ongoing development. For teams running large Java or Scala monorepos and evaluating Cursor or VS Code as an IntelliJ replacement, Metals v2 is the first credible path—with the caveat that Bazel and full refactoring support remain in progress.