Databricks open-sourced Metals v2 on August 11, giving any organization running a large Java or Scala monorepo a language server that delivers fast, low-setup code navigation inside Cursor, VS Code, and Neovim.
Back to NewsDatabricks open-sourced Metals v2 on August 11, making it available to any organization that runs a large Java or Scala codebase. The release is available today in Cursor, VS Code, and Neovim.
Metals has been the official Scala language server for years. Version 2 adds first-class Java support, and that addition is already drawing serious attention. Companies with some of the largest Java codebases in the industry are now piloting Metals for Java alone.
A language server is the software layer that gives an editor features like jump-to-definition, symbol search, and inline diagnostics. The Language Server Protocol (LSP) standardizes how editors and language servers communicate. The problem for large Java and Scala teams is that existing LSP implementations were not designed for monorepos that run to tens of millions of lines.
At Databricks, that meant IntelliJ had set the standard for years because it was effectively the only editor that could keep up with the scale of their monorepo. That created a tooling monoculture: one vendor, one licensing model, and limited room to optimize the development platform in a single direction.
In May 2025, Databricks began standardizing its daily editor workflow around Cursor. Cursor and VS Code were already in use for frontend and non-JVM work, and both had strong SSH remote support for cloud-based development. The gap was JVM. Scala and Java services at that scale had no viable path through existing language servers.
The Databricks team forked Metals v1 and reworked three central layers to hit a metric they defined as time-to-initial-intelligence, or TTII. TTII measures how quickly the editor becomes useful after opening the repository, from language server activation to the moment fuzzy symbol search, jump-to-definition, and cross-repository usage finding are all available.
First, Metals v2 removes the Build Server Protocol from the startup critical path by indexing workspace sources directly. In v1, the language server waited for a build server to supply the initial project model. In v2, Metals owns that model from the start.
Second, Metals v2 moves symbol loading from a build-provided classpath into a Metals-provided sourcepath. That means diagnostics and navigation reflect the actual code on disk rather than a stale snapshot from the last successful compilation.
Third, the build integration boundary was redesigned around metadata-first build integration.
Together, these changes let engineers navigate a 26-million-line monorepo with fast startup and without manual build configuration.
Most code at Databricks is now written by agents. That single fact reframes what a language server needs to do. When agents handle the bulk of code generation, engineers reach for their editor to orient themselves in a large codebase, review agent output, and debug specific problems. They need fast startup and reliable navigation. They need low setup cost. Broad autocomplete and deep refactoring coverage, the features that historically justified heavyweight IDEs, become less central.
That shift also changes the economics of IDE consolidation. A unified IDE platform creates a flywheel: teams share a baseline for exploration and development while the platform team concentrates investment in one place rather than maintaining tooling for several editors.
Databricks did not renew the majority of its IntelliJ seats this year after consolidating onto Cursor. As of July 2026, 92% of weekly active IDE users open Cursor, compared to 12% for IntelliJ. Among engineers using only one IDE, 2.4k are on Cursor and 120 are on IntelliJ. Cursor's share of Scala and Java file open events rose from 40% to 78% between October 2025 and July 2026.
The pattern held at other large JVM shops. Stripe began rolling out Metals v2 less than a month ago as of the August 11 release post and reported strong early results in its Java codebase. Ongoing development is led by VirtusLab, which maintains the upstream Metals project and worked with Databricks and the Cursor team to bring the v2 work back into the open-source community.
Kevin Niparko of Cursor said the team is contributing to Metals v2 to make Cursor work well for multi-million line Java codebases, with a focus on improving Bazel support, debugging, and testing. Krzysztof Romanowski, Head of Development Productivity at VirtusLab, described the direction as "fast startup, reliable codebase orientation, and an architecture built for large codebases."
For data platform owners and business-system teams whose engineering organizations run significant Java or Scala services, this release touches two decisions.
The first is IDE tooling cost. If your organization holds a large IntelliJ fleet and is already using Cursor or VS Code for other work, Metals v2 removes the main technical obstacle to consolidation on the JVM side. That is a real licensing and platform-operations question worth scoping.
The second is agent-era tooling design. If agents are writing a growing share of your team's code, the IDE features you optimize for should shift accordingly. Setup friction and navigation speed matter more. Refactoring depth matters less. Metals v2 is designed around exactly that premise, and Databricks' internal data gives you a credible before-and-after to evaluate.
The immediate action is straightforward: identify which teams in your organization work with large Java or Scala codebases, check whether they are already using Cursor or VS Code for other languages, and test Metals v2 against your actual monorepo size and build tooling. Installation instructions are available on the Metals website, and the GitHub issue tracker is the path for feedback and contributions.
