Project: Metals - the Scala and Java language server
Role: VirtusLab maintains Metals as open-source infrastructure for the Scala and JVM community, powering Scala and Java support in Cursor, VS Code, and Neovim.
In 2026, Databricks ran into a problem the whole industry is starting to feel. Agents write most of the code now. When engineers do go hands-on, they need an editor that starts fast and gets them oriented fast - not one built around typing everything by hand.
At the scale of Databricks' monorepo - 26 million lines - no lightweight editor could do that.
Metals v2 closed the gap. VirtusLab worked with Databricks to build it, then generalized and open-sourced it under Apache 2.0, so any team with a large JVM codebase can use it - not just the one that funded the original work.
This post covers the problem, how Metals v2 solves it, and what it unlocked. All figures below come from Databricks' own engineering post.
AI is changing what developers need from an editor. As agents write more of the code, engineers spend less time typing and more time orienting themselves - so fast startup and reliable navigation matter more than deep autocomplete or refactoring.
That favors lightweight editors, already winning for frontend work and strong on SSH-remote support. Databricks wanted to standardize on one: a single baseline for code exploration, a single place to invest.
The catch: their monorepo runs 142k+ Scala, Java, and Protobuf files, and 285k Bazel JVM targets.
Metals v1 hit the wall every lightweight-editor language server hits at this scale: it waited on the build server for its initial project model, too slow to be useful the moment you open the repo. No existing JVM tooling could solve this at Databricks' scale.
An internal prototype proved a build-free, compiler-backed approach could work. VirtusLab took it from there - generalizing it, hardening it and bringing it back into the open-source project as Metals v2.
Three layers changed.
1. A build-free repo index (mbt). Metals v2 gets the Build Server Protocol off the startup path entirely. It indexes workspace sources itself, using git ls-files --stage and Git blob OIDs - package declarations, definitions, bloom filters for referenced identifiers, all before any build sync runs. That's what makes fuzzy search, jump-to-definition, and cross-file diagnostics available almost the moment you open the editor.
2. Compiler-backed pipelines for Scala and Java. For Scala, one presentation-compiler instance holds the whole multi-million-line codebase in scope. It switches between a permissive "fallback" mode - useful even on code that doesn't compile yet - and a build-accurate "precise" mode once a sync completes. For Java, the LSP surface is built directly on javac APIs, with a modified Turbine header compiler keeping symbol resolution fast at scale.
3. Metadata-first build integration. Metals v2 still talks BSP to the build server, but the contract is narrower. Routine diagnostics no longer depend on it. BSP is mostly for building metadata now - dependencies, generated sources, test discovery, debug launchers - and only on explicit user action, never as background startup work.
Straight from Databricks' production rollout, across their 26-million-line monorepo:
Metric
Result
Weekly-active IDE share on their preferred lightweight editor for JVM work
92% by July 2026, after a growth plateau that held for months
Scala/Java file-open share on that editor
40% → 78% after the first Metals v2 improvements landed
Engineers standardized on a single lightweight editor
2.4k, vs. 120 on the previous incumbent
Time-to-initial-intelligence (editor open → search, jump-to-definition, find-usages ready)
p50 8.7s / p90 36.7s
Jump-to-definition across a 24M-line Scala codebase
p50 7ms / p90 575ms
Fuzzy symbol search across 2.9M workspace symbols
p50 10ms / p90 95ms
Java throughput via the modified Turbine header compiler
~1M lines/sec
Bazel JVM targets queryable at editor latency
285k
These are Databricks' numbers, from their own production environment - not a VirtusLab benchmark. We cite them because they're the clearest public evidence of what this architecture does at real scale.
Metals v2 was always meant to go back to the community, not stay one company's fork.
VirtusLab now leads its ongoing development in the open, with a stable release in progress to replace Metals v1.
Other large JVM codebases are hitting the same wall: demand for lightweight, SSH-remote-capable editors, pressure toward unified tooling, no existing language server built for monorepo scale. Stripe started rolling out Metals v2 in its Java codebase and saw strong results within a month.
“We began rolling out Metals V2 at Stripe less than a month ago, yet we're constantly impressed with how well it works in our Java codebase, the excitement from our engineers, and how delightful it is to work with and learn from the maintainers.”
Mahib Hosain, Developer Platform, Stripe
“AI is changing how developers use IDEs, and Metals v2 moves in the right direction: fast startup, reliable codebase orientation, and an architecture built for large codebases. Databricks validated the approach at exceptional scale, and VirtusLab is excited to help bring this work to the broader Scala and JVM community”
Krzysztof Romanowski, Head of Development Productivity, VirtusLab
This isn't an argument that lightweight editors beat full-featured IDEs. It's that a real lightweight option didn't exist before Metals v2, for one specific and growing workflow: agent-heavy development on very large JVM monorepos.
IntelliJ remains a strong, deeply capable environment for JVM development. JetBrains is investing heavily in the same underlying shift - Air, a workspace for running multiple coding agents at once, and JetBrains Central, a control plane for governing agent-driven work across an org's tools.
Databricks needed an IDE built for how software gets written now: fast to start, easy to orient in, able to keep up with agents doing most of the coding. No existing JVM language server delivered that at their scale.
Metals v2 closed the gap - not by tuning the old architecture, but by rethinking the repo index, the compiler pipelines, and the build integration boundary from first principles.
That's what VirtusLab does as Metals' maintainer: take something proven at one company's scale and turn it into infrastructure the rest of the ecosystem can build on. Databricks, Stripe, and others are already running on it.
VirtusLab maintains Metals, the official Scala and Java language server, and works with engineering teams to modernize dev tooling and build systems at scale - Bazel migrations, remote execution, IDE and language-server infrastructure for some of the largest JVM codebases around.
Still waiting on the build server before your editor wakes up?
If your team is losing minutes every time someone opens the editor - or your monorepo has simply outgrown what standard JVM tooling can index - VirtusLab's Metals team can help you get there.
