Mahib Hosain / Stripe / Open-source contributions
Metals + Bazel
Java at monorepo scale
I led Stripe’s Metals V2 rollout, built the BSP server connecting Bazel to the editor, and contributed upstream fixes for Java, generated sources, and protobuf navigation.
- 26M lines
- JVM repository context at Stripe
- BSP
- A shared build interface for language tooling
- VS Code / Cursor
- Editor integration with Metals V2
The integration
A successful build is not enough for a useful editor. The language server also needs accurate source ownership, generated files, dependency classpaths, and current test information.
I worked with engineers at Cursor and Databricks, including onsite discussions, on Java support at Stripe’s scale. My work spanned the internal Bazel/BSP integration and contributions to the public Metals and VS Code extension repositories.
- BazelBuild targets and generated sources
- BSP serverBuild metadata for the editor
- MetalsLanguage intelligence
- VS Code / CursorNavigation, diagnostics, tests
Engineering decisions
Resolve generated files to their build targets
Generated Java sources and symlinked roots need reliable target ownership. My upstream changes connect those files to the right build context and avoid stale diagnostics or inappropriate compile-on-focus behavior.
Prefer the target’s classpath, keep a fallback
When target classpaths and Turbine headers provide the same class, the target’s classpath takes priority. Headers remain a fallback for dependency symbols. Regression coverage checks generated protobuf builder methods; refreshed indexing includes Java package information.
Use current test information
Java Bazel test code lenses check the current SemanticDB document before offering run/test actions, so the editor uses current test-class information.
Fit the language server into existing tooling
A custom launcher allows the VS Code extension to start a Metals-compatible stdio server through existing proxy and observability tooling. Normal language-client wiring stays in the extension.
Public evidence
These contributions were made under my work account, mahib-stripe. The linked PRs contain the implementation, review context, and verification notes.
- Metals #8800 — Target classpaths and protobuf resolution ↗
Prioritize target classpaths over Turbine headers; generated builder methods and Java package indexing
- Metals #8590 — BSP-generated Java sources ↗
Source ownership, symlinked roots, navigation, and stale diagnostics
- Metals #8607 — Java Bazel test code lenses ↗
Use current SemanticDB test-class information for editor test actions
- Extension #1963 — Custom server launcher ↗
Integrate existing LSP proxy and observability tooling
- Extension #1998 — Protobuf document selection ↗
Proto and prototext support, including proto-to-proto navigation
- Extension #2039 — Activation behavior revert ↗
A revert of language-based proto/prototext activation, not a new feature
I’m also quoted in Databricks’ Metals V2 launch article. The 26M-line figure describes Stripe’s JVM repository, not an independently measured user count. This case study documents my contribution to a wider collaborative project; the internal BSP implementation remains private.