Por Que Você Deveria Parar de Usar Lombok AGORA

Project Lombok, uma biblioteca amplamente usada por desenvolvedores Java para reduzir boilerplate code, tem sido alvo de polêmicas desde o seu lançamento. Neste texto, exploraremos as principais razões para evitar o uso de Lombok em projetos modernos, considerando as consequências de sua adoção e alternativas mais sustentáveis no ecossistema Java. Ao final, esperamos oferecer uma visão clara e fundamentada sobre a viabilidade dessa biblioteca nos dias atuais.

Uma Perspectiva Baseada em Experiência

Programando desde 2008, tive a oportunidade de trabalhar com diversos frameworks e bibliotecas no ecossistema Java. No entanto, só utilizei Lombok em dois projetos específicos. O primeiro foi para um sistema de análise de crédito no PagSeguro, e o segundo, em um projeto para o Ministério da Saúde. Curiosamente, em ambos os casos, a missão era justamente remover o Lombok devido aos inúmeros problemas que ele havia causado ao longo dos anos. Essas experiências reforçaram minha percepção de que Lombok não é uma solução adequada para projetos que prezam por TDD, Clean Code, cobertura de código, SOLID ou padrões de projeto.

Pessoas influentes na área de desenvolvimento, como Uncle Bob (Robert C. Martin), Martin Fowler, Kent Beck e outros defensores de boas práticas, jamais recomendariam Lombok. Isso porque ele viola diversos princípios fundamentais do desenvolvimento de software sustentável e escalável. É comum encontrar o uso de Lombok apenas em tutoriais online onde o autor não se preocupa em abordar boas práticas de programação ou conceitos essenciais para a manutenção de código de qualidade.

Dependência Excessiva em uma Biblioteca Não Oficial

Uma das maiores preocupações com Lombok é que ele não faz parte da especificação oficial do Java. Isso significa que você está confiando em uma solução externa para manipular partes fundamentais do seu código, como getters, setters e construtores. Caso o projeto seja descontinuado ou incompatível com futuras versões do Java, a migração pode se tornar um pesadelo. No histórico do Java, houve situações onde mudanças na linguagem quebraram soluções não oficiais, e a dependência em uma biblioteca de terceiros amplia esse risco.

Além disso, confiar em uma biblioteca externa para tarefas tão essenciais pode comprometer a independência do projeto. Em ambientes corporativos, onde a sustentabilidade do código é crítica, confiar em soluções que fogem do padrão da linguagem é um risco que nem sempre vale a pena correr. Enquanto isso, linguagens como Groovy, Kotlin, Scala e JRuby, bem como a evolução oficial do Java, oferecem alternativas mais seguras e modernas, sustentadas por empresas reconhecidas no mundo do desenvolvimento de software, como JetBrains, Pivotal e Oracle.

Exemplo com Lombok:

import lombok.Data;

@Data
public class User {
    private String name;
    private String email;
}

Sem Lombok (Código explícito):

public class User {
    private String name;
    private String email;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

Problemas de Debug e Legibilidade

Lombok gera código automaticamente em tempo de compilação, o que pode dificultar o debug. O código gerado nem sempre é visível diretamente para os desenvolvedores, tornando mais difícil identificar erros ou compreender o comportamento inesperado da aplicação. Essa “mágica” reduz a clareza do código e pode causar confusão, especialmente para novos membros da equipe que precisam entender rapidamente como as classes foram projetadas.

Em um cenário de manutenção, onde cada segundo conta para localizar e corrigir bugs, a falta de transparência pode gerar atrasos significativos. Além disso, mesmo desenvolvedores experientes podem enfrentar desafios ao tentar entender a lógica que foi gerada automaticamente. Isso prejudica a colaboração e a eficiência no trabalho em equipe.

Impacto no Build e em IDEs

Integrar Lombok pode ser problemático em ambientes de desenvolvimento. Ferramentas como IntelliJ IDEA e Eclipse precisam de plugins específicos para interpretar as anotações de Lombok corretamente. Além disso, problemas de compatibilidade entre a biblioteca e ferramentas de build, como Maven e Gradle, podem surgir, especialmente após atualizações.

Esses desafios podem escalar rapidamente em equipes grandes ou em projetos onde múltiplas versões de ferramentas são usadas. A necessidade de configurar plugins adicionais para cada desenvolvedor ou ambiente de CI/CD também adiciona complexidade desnecessária ao processo. Isso impacta diretamente o onboarding de novos membros da equipe e a velocidade de entrega do projeto.

Dificuldades em Testar e Criar Mocks

Outro problema significativo do Lombok é a dificuldade que ele introduz em testes e mocks. Como o código gerado por Lombok é invisível no código-fonte, bibliotecas de mock, como Mockito e EasyMock, podem apresentar problemas ao tentar interceptar métodos gerados automaticamente. Essa opacidade no código gerado também dificulta a escrita de testes unitários detalhados que verifiquem o comportamento exato dos métodos da classe.

Além disso, cenários onde precisamos de controle refinado sobre getters, setters ou construtores podem se tornar inviáveis com Lombok, já que ele abstrai completamente essa lógica. Isso contraria princípios fundamentais de testabilidade, como o controle sobre o comportamento dos objetos em diferentes cenários de teste. No desenvolvimento orientado por testes (TDD), essa falta de visibilidade e flexibilidade pode comprometer seriamente a qualidade e a confiança nos testes.

Redução da Portabilidade do Projeto

Ao adotar Lombok, você aumenta o acoplamento entre o código-fonte e a biblioteca. Em casos onde o projeto precisa ser portado para outras linguagens ou mantido sem o uso de Lombok, como em fusões de equipes ou projetos legados, a refatoração pode demandar um enorme esforço. Além disso, muitos sistemas corporativos preferem código “puro” por ser mais previsível e padronizado.

Essa dependência também limita a flexibilidade para adotar novas tecnologias. Projetos modernos frequentemente exploram frameworks e linguagens mais dinâmicas, e o uso de Lombok pode ser um obstáculo nesses casos, forçando refatorações custosas. Esse tipo de limitação pode afetar a capacidade de inovação e a longevidade do sistema.

Alternativas Modernas no Ecossistema Java

Com a evolução do Java, muitas funcionalidades que Lombok oferecia se tornaram nativas. Por exemplo, o Java introduziu “records” na versão 14 como uma solução oficial para classes imutáveis, eliminando grande parte da necessidade de anotações como @Data.

Exemplo usando Records no Java:

public record User(String name, String email) {}

Os records são imutáveis, o que os torna ideais para muitos casos de uso. Entretanto, sua natureza imutável também pode ser uma limitação em projetos que demandam mutabilidade. Para cenários onde mutabilidade é necessária, linguagens como Groovy e Kotlin fornecem soluções práticas e integradas diretamente ao ecossistema Java.

Exemplo com Kotlin (data class):

data class User(var name: String, var email: String)

Em Kotlin, os data classes geram automaticamente getters, setters (para propriedades mutáveis), métodos equals, hashCode, toString e um copy. Isso fornece flexibilidade e reduz a quantidade de código boilerplate, sem a necessidade de bibliotecas adicionais.

Exemplo com Groovy:

@Canonical
class User {
    String name
    String email
}

No Groovy, os getters e setters são gerados implicitamente, mesmo sem anotações. Isso significa que o bytecode final terá os métodos necessários de maneira transparente, similar a uma classe Java tradicional. A anotação @Canonical adiciona automaticamente métodos úteis como toString, equals e hashCode.

Usando Classes Groovy e Kotlin no Java

Classes criadas em Groovy e Kotlin são completamente compatíveis com código Java. Por exemplo, uma classe Groovy ou Kotlin pode ser usada diretamente em um projeto Java:

Classe Groovy:

User user = new User("John Doe", "john.doe@example.com");
user.setName("Jane Doe");
System.out.println(user.getName());

Classe Kotlin:

User user = new User("John Doe", "john.doe@example.com");
user.setName("Jane Doe");
System.out.println(user.getName());

Compatibilidade com JPA/Hibernate e Frameworks do Ecossistema Java

Tanto Groovy quanto Kotlin são altamente compatíveis com frameworks como JPA/Hibernate, Jackson e Spring. Em Kotlin, a mutabilidade das propriedades pode ser controlada com var e val, permitindo modelar entidades JPA facilmente. No Groovy, o suporte a anotações Java padrão facilita a integração sem esforço adicional.

Frameworks como Jackson também lidam bem com classes Groovy e Kotlin, devido à geração de métodos padrão como getters e setters. Isso garante que a serialização e desserialização funcionem sem a necessidade de configurações específicas.

Possíveis Problemas de Manutenção

Código gerado automaticamente é, muitas vezes, menos flexível e mais propenso a criar armadilhas durante manutenções futuras. Por exemplo, uma alteração em um campo pode exigir um controle maior sobre getters e setters, algo que Lombok abstrai completamente. Nessas situações, a abstração fornecida por Lombok se torna mais um obstáculo do que uma vantagem.

Além disso, a falta de controle granular sobre o código gerado dificulta a adaptação do sistema a requisitos específicos, como mudanças em lógica de negócios ou conformidade com padrões corporativos. Em equipes grandes, isso pode levar a retrabalho e perda de eficiência.

Problemas de Conformidade com Auditorias

Em organizações que seguem padrões rigorosos de auditoria, o uso de Lombok pode ser um problema. Código invisível ou magicamente gerado é mais difícil de justificar para auditores, que preferem ver implementações explícitas para assegurar que a aplicação atende aos requisitos de segurança e conformidade.

Além disso, ambientes regulados frequentemente exigem documentação detalhada e previsibilidade. O uso de Lombok, com sua abordagem de “código invisível”, pode comprometer a capacidade de atender a esses requisitos, especialmente em indústrias como finanças e saúde.

Conclusão

Embora Lombok tenha sido uma solução útil para reduzir boilerplate no passado, as mudanças recentes no Java e as limitações da própria biblioteca tornam seu uso menos vantajoso nos dias de hoje. A preferência por soluções nativas, maior clareza no código e menor dependência de ferramentas externas são tendências que ajudam a garantir a longevidade e a manutenção do projeto.

Explorar linguagens modernas como Kotlin e Groovy oferece uma alternativa poderosa para evitar a dependência em bibliotecas externas. Além de reduzir o código boilerplate, essas linguagens introduzem funcionalidades que enriquecem o ecossistema Java, sem sacrificar a compatibilidade com frameworks populares como JPA/Hibernate e Jackson. Adotar práticas modernas assegura sistemas mais robustos, testáveis e fáceis de manter, alinhando-se às exigências de um desenvolvimento sustentável e escalável.

Treinamentos relacionados com essa postagem