Mockito项目的一位维护者在担任该角色10年后宣布卸任，表达了对社区和贡献者的感谢，并希望项目未来能继续发展。

十年维护者卸任声明

Mockito项目长期维护者TimvdLippe于2025年12月28日宣布，将在2026年3月（其担任维护者满十年之际）正式卸任。他在GitHub issue中详细阐述了这一决定背后的三大关键原因：

1. JVM代理变更带来的精力消耗
Mockito 5版本的核心改动是将主构件改为JVM代理，以适配JVM 22的安全限制。但这一变更的推进过程令维护者感到孤立无援——尽管动态代理附着机制存在安全隐患，官方却未提供替代方案，反而将压力转嫁给开源社区。维护者认为，这种缺乏协作的方式忽视了志愿者项目的脆弱性，正如经典XKCD漫画所揭示的："整个开源世界依赖少数人的无偿付出"。

2. Kotlin支持的技术困境
Kotlin语言的流行迫使Mockito在核心代码中增加大量特殊处理逻辑，尤其是对协程等非常规JVM特性的支持。这种"打补丁式"开发导致代码结构复杂化，API重复率高，维护体验显著下降。维护者直言："当Kotlin的底层实现与JVM设计理念冲突时，维护工作变得不再有趣。"

3. 开源兴趣的转移
近年来，维护者从Rust语言项目Servo的开发中重新获得编程乐趣。当晚间有限的自由时间需要在Mockito和其他项目间分配时，前者逐渐被视为"义务劳动"而非激情所在。他强调："志愿工作不应长期让人感到负担。"

过渡计划
未来三个月内，维护者将确保权力平稳交接，具体讨论将通过新issue进行。他特别指出，上述挑战对继任者可能不成问题（例如有人更热衷Kotlin支持），并鼓励更多人参与开源维护："这是一段值得珍视的荣誉之旅。"

（注：原文中GitHub界面导航、功能菜单等非核心内容已精简，保留核心决策逻辑与关键技术细节）

这篇评论主要围绕Mockito维护者离职及Java生态系统的变化展开讨论，观点如下：

1. 对Mockito项目的理解与疑问

• 有评论者介绍Mockito是"Java最流行的模拟框架"("most popular mocking framework for Java")
• 有人质疑为什么Java需要模拟库："Interface based polymorphism is not enough?"

2. 对维护者离职的看法

• 理解离职决定但质疑技术理由："I respect the maintainer's decision, but I don't understand the justification"
• 同情开源维护困境："Sad to see an important project's core maintainer leave...especially given they felt the JVM ecosystem was causing them pain"

3. 关于技术变更的争议

• 担忧破坏性变更影响企业采用："Wouldn't this hold back enterprise adoption"
• 讨论Java的完整性原则："Integrity is the ability of code to locally declare its reliance on some invariant"
• 质疑Kotlin支持的必要性："Why support Kotlin in the first place...perhaps the Kotlin user base is better served by a Kotlin-specific mocking framework"

4. 替代方案建议

• 建议使用伪造对象替代模拟："This is a good opportunity to ditch mocking and use fakes with adapters"
• 批评Kotlin的重复造轮子："F Kotlin and their approach of 'we'll reinvent the wheel with slightly different syntax'"

5. 技术概念讨论

• 询问代理机制含义："What does Agent mean in this context"
• 解释动态代理变更背景："dynamic attachment of agents' is put behind a flag"

关键引用： - "Mockito is holding the JVM ecosystem back by using dynamic attachment" - "Integrity by Default...means that code in one component can violate invariants established by code in another component only if the application is made aware of it" - "mocks create brittle tests that often test only the framework itself"