Em março de 2026, serei o mantenedor do Mockito por 10 anos (quase um terço de toda a minha vida). Olhando para o futuro, decidi que o marco de uma década é um bom momento para passar a manutenção a outras pessoas. Nos próximos meses, até março, dedicarei algum tempo para garantir uma transição tranquila na manutenção.
Nesta edição listo diversas considerações que me levaram a tomar essa decisão. A comunicação e a discussão dos planos para manutenção futura estarão em outro lugar, provavelmente em uma edição separada do GitHub. Fique atento para isso.
Dreno de energia devido à mudança do agente JVM
Como você deve saber, o Mockito 5 lançou uma mudança significativa em que seu artefato principal agora é um agente. Isso ocorre porque a partir da JVM 22, a chamada “anexação dinâmica de agentes” anterior é colocada atrás de um sinalizador. Esta mudança faz sentido do ponto de vista da segurança e eu apoio-a.
No entanto, a forma como isso foi apresentado aos mantenedores do Mockito consumiu energia, para dizer o mínimo. Mockito é provavelmente o maior usuário desse agente e é frequentemente buscado como inspiração em outros projetos. Como tal, Mockito é frequentemente pioneiro no suporte a recursos JVM, construídos sobre uma base sólida com ByteBuddy. Módulos foi um recurso que levou meses de trabalho árduo de Rafael para ser descoberto, incluindo o fornecimento de feedback aos mantenedores da JVM.
Infelizmente, esta forma colaborativa de trabalhar não foi o caso quando se discutiu agentes. Para mim, parecia que o recurso foi apresentado como um negócio fechado por causa da segurança. Embora a ligação dinâmica seja problemática em muitos aspectos, não foram propostas soluções alternativas. Tudo bem, já que Mockito é pioneiro nessas soluções, mas neste caso senti que fomos deixados em paz.
Minha opinião pessoal é que as pessoas envolvidas na mudança subestimaram severamente o impacto social que ela teve. O fato de não existir suporte adequado à construção até hoje mostra que os agentes não são uma prioridade. Tudo bem se não for uma prioridade, mas quando foi comunicado ao Mockito eu percebi como “Mockito está impedindo o ecossistema JVM usando anexo dinâmico, mude imediatamente e descubra por conta própria”.
Aqui, o fato de eu (e outros) sermos voluntários fazendo o melhor para o projeto é importante para entender o impacto social. Quando você pressiona indivíduos que fazem esse trabalho em seu próprio tempo por boa vontade, as coisas desmoronam. É comum brincar com os XKCDs sobre o fato de que todo o mundo do código aberto depende de alguns indivíduos. Isso não poderia ser mais verdadeiro nesta situação, onde o sistema colaborativo entra em colapso quando muita pressão é colocada sobre os indivíduos.
Esta saga plantou a semente para reconsiderar minha posição como mantenedor.
Kotlin como o futuro e estranho
É inegável que a popularidade do Kotlin como linguagem cresceu nos últimos anos. Embora o Mockito mantenha vários sabores para linguagens JVM, esses pacotes normalmente incluem açúcar que torna a integração mais agradável. Em todos os casos, o mockito-core continua sendo o local onde a funcionalidade é implementada.
Infelizmente, esse modelo não se aplica bem ao Kotlin. Enquanto quase todas as linguagens JVM funcionam de maneira semelhante, o Kotlin geralmente faz as coisas de maneira diferente. Isso significa que em vários lugares do mockito-core, existem fluxos separados dedicados ao Kotlin. Na maioria das vezes, isso é resultado direto de Kotlin fazer (na minha opinião) travessuras na JVM que a JVM nunca pretendeu suportar, mas foi capaz de fazê-lo.
Mesmo dentro do próprio Kotlin, os recursos não funcionam de forma consistente. As funções de suspensão são o exemplo mais conhecido. Como tal, o código Mockito se torna mais espaguete, sua API às vezes é totalmente duplicada apenas para oferecer suporte a um recurso principal da linguagem Kotlin e, em geral, menos sustentável.
Embora eu compreenda perfeitamente os motivos pelos quais os desenvolvedores aproveitam a riqueza de recursos do Kotlin como linguagem de programação, sua implementação subjacente tem desvantagens significativas para projetos como o Mockito. Francamente, não é divertido lidar com isso.
Para mim, um futuro onde Kotlin se torne mais predominante não é um futuro que me dê esperança de poder continuar dedicando energia ao Mockito.
Atividades alternativas de código aberto
Sempre fui um fã do trabalho de código aberto e contribuí para centenas de projetos em todos esses anos. Mockito é meu projeto mais importante, mas também trabalhei consistentemente em outros. Nos últimos meses, redescobri a alegria de programar trabalhando no Servo. É um mecanismo web escrito em Rust.
Quando preciso escolher como quero passar minhas 2 horas noturnas em uma determinada semana, raramente preferi o Mockito no ano passado. No passado, Mockito era minha preferência e eu gostava muito. Hoje em dia, Servo e projetos relacionados proporcionam muito mais diversão.
Justificar por que precisei trabalhar no Mockito torna-se difícil quando (por causa dos motivos acima) parece uma tarefa árdua. O trabalho voluntário não deve parecer uma tarefa árdua, pelo menos não por muito tempo.
Resumindo
Como você leu, esses três fatores combinados me levaram à decisão. O primeiro ponto explica porque comecei a duvidar da minha posição, o segundo ponto porque não tenho esperança de que as coisas mudem no bom sentido e o terceiro ponto como encontrei prazer de uma forma diferente.
Embora esses pontos tenham tido impacto sobre mim como mantenedor, minha hipótese é que isso não se aplica a outros da mesma forma. Sei que outras pessoas estão ansiosas para trabalhar no suporte Kotlin, por exemplo. Por isso concluí que uma década é tempo suficiente para ajudar Mockito a avançar. Agora é hora de outra pessoa assumir o controle, pois acredito que isso é do interesse do Mockito como projeto. Porque, em última análise, foi por isso que escolhi me tornar mantenedor: acreditei que, com meu trabalho, poderia melhorar o Mockito para milhões de engenheiros de software.
Para aqueles que estão se perguntando: sim, aconselho sinceramente a todos que assumam uma tarefa voluntária, como manter um projeto de código aberto. Foi uma honra e um privilégio fazê-lo e agradeço àqueles com quem gostei de trabalhar.
Fonte: theverge
