In March 2026, I will be Mockito maintainer for 10 years (nearly a third of my whole life). Looking ahead, I decided that a decade milestone is a good moment to pass on maintainership to other folks. In the coming months until March, I will spend time ensuring a smooth transition in maintainership.
In this issue I list several considerations why I made the decision. Communication and discussion of plans for future maintainership will be somewhere else, most likely in a separate GitHub issue. Stay tuned for that.
Energy drain because of JVM agent change
As you might know, Mockito 5 shipped a breaking change where its main artifact is now an agent. That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag. This change makes sense from a security point-of-view and I support it.
However, the way this was put forward to Mockito maintainers was energy draining to say the least. Mockito is probably the biggest user of such an agent and is often looked at for inspiration by other projects. As such, Mockito often pioneers on supporting JVM features, built on a solid foundation with ByteBuddy. Modules was such a feature that took months of hard work by Rafael to figure out, including providing feedback to JVM maintainers.
Unfortunately such a collaborative way of working was not the case when discussing agents. To me, it felt like the feature was presented as a done deal because of security. While dynamic attachment is problematic in many ways, no alternative solutions were proposed. That's okay, as Mockito pioneers on these solutions, yet in this case I felt we were left alone.
My personal take is that folks involved with the change severely underestimated the societal impact that it had. The fact that proper build support is non-existent to this day shows that agents are not a priority. That's okay if it isn't a priority, but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own".
Here, the fact that I (and others) are volunteers doing their best for the project, is important to understand the societal impact. When you put individuals under pressure, who do this work in their own time out of goodwill, things crumble. It's commonly joked about with XKCD's on the fact that the whole open source world relies on a couple of individuals. That couldn't be more true in this situation, where the collaborative system collapses when too much pressure is put on individual folks.
This saga planted the seed to reconsider my position as maintainer.
Kotlin as the future and odd one out
... continue reading