# Multi-Language Teams: Beyond JVM Mocking

**Short answer:** A JVM mock is a single-language target; a spec mock is generated from the contract and serves every client. For a polyglot team, the shared contract is the only way to keep the Node, Python, Go, and Java clients aligned to the same API.

## What a single-language mock provides

Maximum control for the JVM tests and no target for the other clients. The non-JVM clients either hit a live server or maintain their own mocks.

## What a shared spec mock provides

| Property | JVM mock | Spec mock |
| --- | --- | --- |
| Clients served | JVM | All |
| Source | Stub code | Contract |
| Alignment | One client | Every client |
| Maintenance | Per language | One spec |

## Why the shared target matters

When every client develops against the same mock, a contract change is reflected once and the clients cannot drift apart. Separate mocks multiply the maintenance.

## The decision rule

Use a JVM mock for a JVM-only codebase. Use a spec mock when the team spans languages.

This is part of the [Powerduck vs WireMock comparison](https://www.powerduck.com/blog/powerduck-vs-wiremock/). Finish with [faults and delays](https://www.powerduck.com/blog/fault-injection-and-delays-compared/).

