Credit where due: stubby4j was a genuinely pleasant stub server. A single fat JAR, human-readable YAML stubs, three tidy portals (stubs on :8882, admin on :8889, TLS on :7443), --watch hot-reload, HTTP/2, WebSockets, regex-capture token replacement, even proxy record & replay. For a decade of Java integration suites it was the sane middle ground between hand-rolled fixtures and heavyweight service virtualization.
The GitHub repository was archived by its owner on June 28, 2025 — it is now read-only: no new issues, no pull requests, no fixes coming. The last release on Maven Central is 7.6.1, published February 8, 2024 (both checked August 2026). The sibling ports the README points to — stubby4node and stubby4net — live in a different author's repos and haven't been the answer for years either. If stubby4j is load-bearing in your test suite, you're now maintaining a fork or planning an exit.
WireMock is the usual Java-world exit ramp and it's a good one — see our WireMock Cloud notes for how its hosted tier prices out. This page is about a different exit: if what you were actually using stubby4j for is mocking a plain HTTP/JSON API — for a frontend, a mobile app, CI, or a teammate — you can stop maintaining stub files entirely.
We downloaded the final 7.6.1 JAR from Maven Central and drove it with a plain config — a GET /products stub returning a canned list and a POST /products stub returning a canned 201. Observed behavior:
Wall 1: writes are theater. POST /products returned our canned 201 {"id":2,"name":"created"} — and the next GET /products returned the same one-widget list as before. Nothing was created; the 201 is a recording. There is no state to update — every "write" is a stub whose consequences you also stub.
Wall 2: query params match only exact stubbed values. stubby4j can match on query params — but only literally. Our GET /greet?name=ada stub answered name=ada with 200 and name=bob with 404. And a stub with no query block ignores params entirely: GET /products?page=2&limit=1 returned the same full canned body. Pagination, sorting, filtering — every variant is another YAML stanza, per resource, forever.
Wall 3: it's a localhost JVM process. The JAR binds local ports. The moment a teammate, a deployed preview, CI, or your phone needs the mock, you're provisioning and babysitting a server — and there was never a hosted stubby4j to upgrade to.
One honest point in stubby4j's favor: unmatched paths return a real 404 with a helpful x-stubby4j-http-error-real-reason header — better behavior than several tools we've tested that answer 200-empty.
Where you'd write a YAML file and launch java -jar stubby4j-7.6.1.jar -d stubs.yml, create a hosted project instead — nothing to run, no JVM:
curl -X POST https://mockbird.mockbird.workers.dev/api/projects \
-H 'content-type: application/json' -d '{"name":"my-api"}'
# → {"id":"g3cxybzbx3","adminKey":"…","baseUrl":"https://mockbird.mockbird.workers.dev/m/g3cxybzbx3",…}
curl -X POST https://mockbird.mockbird.workers.dev/api/projects/<PID>/resources \
-H 'x-admin-key: <KEY>' -H 'content-type: application/json' \
-d '{"name":"products","fields":[{"name":"name","type":"words"},{"name":"price","type":"price"}],"seed":5}'
# → 5 realistic seeded records, live at /m/<PID>/productsNow the behaviors you'd hand-stub are just true:
# writes persist (ran against this API before publishing):
curl -X POST …/m/<PID>/products -H 'content-type: application/json' -d '{"name":"added by test","price":1.99}'
# → {"name":"added by test","price":1.99,"id":6}
curl …/m/<PID>/products/6 # → the same record. It's real.
# query params work with zero stanzas — any value, not just stubbed ones:
curl '…/m/<PID>/products?page=2&limit=3&sortBy=price&order=desc&price_gte=100'
# missing records are real 404s (stubby4j got this right; so do we):
curl -i …/m/<PID>/products/999 # → HTTP 404 {"error":"not found"}Have a fixed payload that really is best as a canned stub? Custom routes are one curl — any status, content type, headers, latency, and templating. stubby4j's regex-capture token replacement maps to named path params (we verified this exact route answered {"hello":"ada",…} before publishing):
curl -X POST …/api/projects/<PID>/routes -H 'x-admin-key: <KEY>' \
-H 'content-type: application/json' \
-d '{"method":"GET","path":"/greet/:name","status":200,
"contentType":"application/json","body":"{\"hello\":\"{{params.name}}\",\"at\":\"{{now}}\"}"}'
curl …/m/<PID>/greet/ada # → {"hello":"ada","at":"2026-08-31T21:17:39.818Z"}| stubby4j | Mockbird | Notes |
|---|---|---|
java -jar stubby4j.jar -d stubs.yml | POST /api/projects | hosted URL instead of :8882; nothing to run, no YAML file |
- request:… response:… stanza | custom route | method/path/status/body/headers/contentType/delayMs |
| canned CRUD stubs | real stateful resources | POST→GET-back persists; PUT/PATCH/DELETE; filters/sort/pagination/search built in |
response: latency: 1500 (we measured 1.5 s) | ?mock_delay=1500 | per-request, no config edit — measured 2.4 s for mock_delay=2000 on the shared demo |
| response list on one URI (cycles: we observed 500,200,500,200…) | ?mock_seq=500,200 | semantics differ: ours plays the sequence once and the last value sticks (500,200,200…) — better for retry drills |
| error drills via extra stubs | ?mock_status=503, ?mock_chaos=0.3, ?mock_ratelimit=2 | any endpoint, on cue — guide |
regex capture groups → <% url.1 %> tokens | /greet/:name → {{params.name}} | plus {{query.x}}, {{body.x}}, {{headers.x}}, {{now}}, {{uuid}} |
admin portal :8889/status | request inspector | last 50 requests with headers + bodies, readable from tests via API |
admin portal POST API / StubbyClient | management REST API | everything the dashboard does is a curl |
--watch hot reload | edits are live instantly | server-side persistence — there's no file to reload |
| proxy config / record & replay | proxyBase + proxyRecord | record a real API once, replay hosted — docs |
TLS portal :7443, self-signed cert | HTTPS by default | real certificate, no -k flags in your tests |
| WebSockets stubbing (v7.6+) | WS echo only | honest: scripted WS conversations have no equivalent here |
| HTTP/2 over TLS (h2) | HTTP/2 by default | Cloudflare edge negotiates h2/h3 automatically |
| YAML in your repo | snapshots + db.json export | save/restore named data states; eject your data anytime |
# query params that actually work — no YAML stanzas written:
curl 'https://mockbird.mockbird.workers.dev/m/demo/products?page=2&limit=3'
# latency-behavior equivalent, per request (measured 2.4s):
curl 'https://mockbird.mockbird.workers.dev/m/demo/products/1?mock_delay=2000'
# their cycling response list, as a one-shot retry drill:
curl 'https://mockbird.mockbird.workers.dev/m/demo/products?mock_seq=500,200&mock_seq_key=me1'
# → 500 on the first call, 200 after
# writes persist — POST it, then GET it back:
curl -X POST 'https://mockbird.mockbird.workers.dev/m/demo/products' \
-H 'content-type: application/json' -d '{"name":"from the stubby4j guide","price":1.99}'| stubby4j | Mockbird | |
|---|---|---|
| Price | free, open source (MIT) | free while in beta |
| Maintenance | GitHub repo archived June 28, 2025 (read-only); last release 7.6.1, Feb 2024 | actively developed |
| Hosted URL others can hit | no — self-host a JVM process | yes — 10,000 requests/project/day, no signup |
| Stateful CRUD (POST → GET it back) | no — canned responses only (verified 7.6.1) | yes — persistent records, snapshots, restore |
| Query params | exact stubbed values only; ignored if not stubbed (verified) | pagination/filter/sort/search always on, any value |
| Unmatched path | real 404 with diagnostic header ✔ | real 404 with a JSON error |
| Protocols | HTTP/1.1, HTTP/2, WebSockets stubbing, TLS portal | HTTP(S) + GraphQL + SSE/WebSocket echo |
| Record & replay proxying | yes | yes — proxyBase + proxyRecord |
| Works offline | yes | no |
| Java in-process embedding | yes (StubbyClient, JUnit-friendly) | no — it's a URL; see the Java guide |
Written by the Mockbird maker — bias disclosed. Where stubby4j genuinely won: in-process JVM embedding for JUnit suites, scripted WebSocket conversations, offline use with no request caps, and YAML stubs that live in your repo and code-review cleanly. Every behavioral claim above was verified by us in August 2026 by running the final stubby4j-7.6.1.jar from Maven Central (stubs on :8882, admin on :8889, config as described); the archive date is from the GitHub repository banner; the release date is from Maven Central. If any of this changes, we'll update the page.
Full API reference in the docs. More guides: WireMock Cloud alternative · MockServer alternative · mountebank alternative · Hoverfly alternative · Karate mock server alternative · mock API for Java · mock API for Spring Boot · mock any custom endpoint · free mock API tools compared. Create your API →