December 28, 2025
Mocks, shocks, and JVM locks
Stepping down as Mockito maintainer after 10 years
Popular Java test tool lead quits; fans blame burnout, rule changes, and Kotlin headaches
TLDR: Mockito’s longtime lead is stepping down after burnout over Java’s new rules and Kotlin headaches. Commenters split between sympathy, confusion about why this change was needed, and fears that enterprises will stick to old Java again — spotlighting how fragile volunteer-run tools can be.
After a decade steering Mockito — a wildly popular tool that helps developers fake parts of their apps to test safely — its lead says he’s stepping back, and the comments section instantly turned into tech reality TV. Newcomers asked “what even is Mockito?” while skeptics wondered if Java really needs a mocking tool at all. Cue explainers, eye-rolls, and links galore.
The spiciest thread: a recent change in Java’s engine (the JVM) pushed Mockito to ship as an “agent,” because the old way of plugging into running apps now needs a security switch. The maintainer says that shift was energy-draining, poorly supported, and rough for volunteers. Commenters rallied with the classic XKCD “one person in Nebraska” meme, blasting big ecosystems for breaking stuff without tooling. Meanwhile, enterprise folks fretted about déjà vu: would this make companies cling to ancient versions forever, like the long reign of Java 8?
Then came the side-quest: Kotlin. Fans love the flashy language, but the maintainer called out Kotlin quirks turning the codebase into spaghetti and duplicating features just to make it work. The vibe: half sympathy for burnout, half confusion (“who pushed this?”), plus a sprinkle of language wars and popcorn-worthy drama.
Key Points
- •The Mockito maintainer plans to step down in March 2026 after 10 years.
- •A smooth maintainership transition is planned, with future discussions likely handled via a separate GitHub issue.
- •Mockito 5 introduced a breaking change making its main artifact a JVM agent due to JVM 22’s flag on dynamic agent attachment.
- •The maintainer found the agent change process energy-draining and lacking collaborative support, citing insufficient build tooling.
- •Supporting Kotlin on the JVM adds complexity to mockito-core (e.g., suspend functions), leading to duplicated APIs and maintainability concerns.