{"id":1864,"date":"2023-01-21T06:07:00","date_gmt":"2023-01-21T09:07:00","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1864"},"modified":"2025-09-23T06:34:03","modified_gmt":"2025-09-23T09:34:03","slug":"por-que-voce-deveria-parar-de-usar-lombok-agora","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/por-que-voce-deveria-parar-de-usar-lombok-agora\/","title":{"rendered":"Por Que Voc\u00ea Deveria Parar de Usar Lombok AGORA"},"content":{"rendered":"\n

Project Lombok, uma biblioteca amplamente usada por desenvolvedores Java para reduzir boilerplate code, tem sido alvo de pol\u00eamicas desde o seu lan\u00e7amento. Neste texto, exploraremos as principais raz\u00f5es para evitar o uso de Lombok em projetos modernos, considerando as consequ\u00eancias de sua ado\u00e7\u00e3o e alternativas mais sustent\u00e1veis no ecossistema Java. Ao final, esperamos oferecer uma vis\u00e3o clara e fundamentada sobre a viabilidade dessa biblioteca nos dias atuais.<\/p>\n\n\n\n

Uma Perspectiva Baseada em Experi\u00eancia<\/h3>\n\n\n\n

Programando desde 2008, tive a oportunidade de trabalhar com diversos frameworks e bibliotecas no ecossistema Java. No entanto, s\u00f3 utilizei Lombok em dois projetos espec\u00edficos. O primeiro foi para um sistema de an\u00e1lise de cr\u00e9dito no PagSeguro, e o segundo, em um projeto para o Minist\u00e9rio da Sa\u00fade. Curiosamente, em ambos os casos, a miss\u00e3o era justamente remover o Lombok devido aos in\u00fameros problemas que ele havia causado ao longo dos anos. Essas experi\u00eancias refor\u00e7aram minha percep\u00e7\u00e3o de que Lombok n\u00e3o \u00e9 uma solu\u00e7\u00e3o adequada para projetos que prezam por TDD, Clean Code, cobertura de c\u00f3digo, SOLID ou padr\u00f5es de projeto.<\/p>\n\n\n\n

Pessoas influentes na \u00e1rea de desenvolvimento, como Uncle Bob (Robert C. Martin), Martin Fowler, Kent Beck e outros defensores de boas pr\u00e1ticas, jamais recomendariam Lombok. Isso porque ele viola diversos princ\u00edpios fundamentais do desenvolvimento de software sustent\u00e1vel e escal\u00e1vel. \u00c9 comum encontrar o uso de Lombok apenas em tutoriais online onde o autor n\u00e3o se preocupa em abordar boas pr\u00e1ticas de programa\u00e7\u00e3o ou conceitos essenciais para a manuten\u00e7\u00e3o de c\u00f3digo de qualidade.<\/p>\n\n\n\n

Depend\u00eancia Excessiva em uma Biblioteca N\u00e3o Oficial<\/h3>\n\n\n\n

Uma das maiores preocupa\u00e7\u00f5es com Lombok \u00e9 que ele n\u00e3o faz parte da especifica\u00e7\u00e3o oficial do Java. Isso significa que voc\u00ea est\u00e1 confiando em uma solu\u00e7\u00e3o externa para manipular partes fundamentais do seu c\u00f3digo, como getters, setters e construtores. Caso o projeto seja descontinuado ou incompat\u00edvel com futuras vers\u00f5es do Java, a migra\u00e7\u00e3o pode se tornar um pesadelo. No hist\u00f3rico do Java, houve situa\u00e7\u00f5es onde mudan\u00e7as na linguagem quebraram solu\u00e7\u00f5es n\u00e3o oficiais, e a depend\u00eancia em uma biblioteca de terceiros amplia esse risco.<\/p>\n\n\n\n

Al\u00e9m disso, confiar em uma biblioteca externa para tarefas t\u00e3o essenciais pode comprometer a independ\u00eancia do projeto. Em ambientes corporativos, onde a sustentabilidade do c\u00f3digo \u00e9 cr\u00edtica, confiar em solu\u00e7\u00f5es que fogem do padr\u00e3o da linguagem \u00e9 um risco que nem sempre vale a pena correr. Enquanto isso, linguagens como Groovy, Kotlin, Scala e JRuby, bem como a evolu\u00e7\u00e3o oficial do Java, oferecem alternativas mais seguras e modernas, sustentadas por empresas reconhecidas no mundo do desenvolvimento de software, como JetBrains, Pivotal e Oracle.<\/p>\n\n\n\n

Exemplo com Lombok:<\/strong><\/p>\n\n\n

\nimport lombok.Data;\n\n@Data\npublic class User {\n    private String name;\n    private String email;\n}\n<\/pre><\/div>\n\n\n
Sem Lombok (C\u00f3digo expl\u00edcito):<\/strong><\/p>\n\n\n
\npublic class User {\n    private String name;\n    private String email;\n\n    public String getName() {\n        return name;\n    }\n\n    public void setName(String name) {\n        this.name = name;\n    }\n\n    public String getEmail() {\n        return email;\n    }\n\n    public void setEmail(String email) {\n        this.email = email;\n    }\n}\n<\/pre><\/div>\n\n\n
Problemas de Debug e Legibilidade<\/h3>\n\n\n\n
Lombok gera c\u00f3digo automaticamente em tempo de compila\u00e7\u00e3o, o que pode dificultar o debug. O c\u00f3digo gerado nem sempre \u00e9 vis\u00edvel diretamente para os desenvolvedores, tornando mais dif\u00edcil identificar erros ou compreender o comportamento inesperado da aplica\u00e7\u00e3o. Essa “m\u00e1gica” reduz a clareza do c\u00f3digo e pode causar confus\u00e3o, especialmente para novos membros da equipe que precisam entender rapidamente como as classes foram projetadas.<\/p>\n\n\n\n
Em um cen\u00e1rio de manuten\u00e7\u00e3o, onde cada segundo conta para localizar e corrigir bugs, a falta de transpar\u00eancia pode gerar atrasos significativos. Al\u00e9m disso, mesmo desenvolvedores experientes podem enfrentar desafios ao tentar entender a l\u00f3gica que foi gerada automaticamente. Isso prejudica a colabora\u00e7\u00e3o e a efici\u00eancia no trabalho em equipe.<\/p>\n\n\n\n\n  \n<\/a>\n\n\n\n
Impacto no Build e em IDEs<\/h3>\n\n\n\n
Integrar Lombok pode ser problem\u00e1tico em ambientes de desenvolvimento. Ferramentas como IntelliJ IDEA e Eclipse precisam de plugins espec\u00edficos para interpretar as anota\u00e7\u00f5es de Lombok corretamente. Al\u00e9m disso, problemas de compatibilidade entre a biblioteca e ferramentas de build, como Maven e Gradle, podem surgir, especialmente ap\u00f3s atualiza\u00e7\u00f5es.<\/p>\n\n\n\n
Esses desafios podem escalar rapidamente em equipes grandes ou em projetos onde m\u00faltiplas vers\u00f5es de ferramentas s\u00e3o usadas. A necessidade de configurar plugins adicionais para cada desenvolvedor ou ambiente de CI\/CD tamb\u00e9m adiciona complexidade desnecess\u00e1ria ao processo. Isso impacta diretamente o onboarding de novos membros da equipe e a velocidade de entrega do projeto.<\/p>\n\n\n\n
Dificuldades em Testar e Criar Mocks<\/h3>\n\n\n\n
Outro problema significativo do Lombok \u00e9 a dificuldade que ele introduz em testes e mocks. Como o c\u00f3digo gerado por Lombok \u00e9 invis\u00edvel no c\u00f3digo-fonte, bibliotecas de mock, como Mockito e EasyMock, podem apresentar problemas ao tentar interceptar m\u00e9todos gerados automaticamente. Essa opacidade no c\u00f3digo gerado tamb\u00e9m dificulta a escrita de testes unit\u00e1rios detalhados que verifiquem o comportamento exato dos m\u00e9todos da classe.<\/p>\n\n\n\n
Al\u00e9m disso, cen\u00e1rios onde precisamos de controle refinado sobre getters, setters ou construtores podem se tornar invi\u00e1veis com Lombok, j\u00e1 que ele abstrai completamente essa l\u00f3gica. Isso contraria princ\u00edpios fundamentais de testabilidade, como o controle sobre o comportamento dos objetos em diferentes cen\u00e1rios de teste. No desenvolvimento orientado por testes (TDD), essa falta de visibilidade e flexibilidade pode comprometer seriamente a qualidade e a confian\u00e7a nos testes.<\/p>\n\n\n\n
Redu\u00e7\u00e3o da Portabilidade do Projeto<\/h3>\n\n\n\n
Ao adotar Lombok, voc\u00ea aumenta o acoplamento entre o c\u00f3digo-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\u00f5es de equipes ou projetos legados, a refatora\u00e7\u00e3o pode demandar um enorme esfor\u00e7o. Al\u00e9m disso, muitos sistemas corporativos preferem c\u00f3digo “puro” por ser mais previs\u00edvel e padronizado.<\/p>\n\n\n\n
Essa depend\u00eancia tamb\u00e9m limita a flexibilidade para adotar novas tecnologias. Projetos modernos frequentemente exploram frameworks e linguagens mais din\u00e2micas, e o uso de Lombok pode ser um obst\u00e1culo nesses casos, for\u00e7ando refatora\u00e7\u00f5es custosas. Esse tipo de limita\u00e7\u00e3o pode afetar a capacidade de inova\u00e7\u00e3o e a longevidade do sistema.<\/p>\n\n\n\n\n  <\/a>\n\n\n\n
Alternativas Modernas no Ecossistema Java<\/h3>\n\n\n\n
Com a evolu\u00e7\u00e3o do Java, muitas funcionalidades que Lombok oferecia se tornaram nativas. Por exemplo, o Java introduziu “records” na vers\u00e3o 14 como uma solu\u00e7\u00e3o oficial para classes imut\u00e1veis, eliminando grande parte da necessidade de anota\u00e7\u00f5es como @Data.<\/p>\n\n\n\n
Exemplo usando Records no Java:<\/strong><\/p>\n\n\n
\npublic record User(String name, String email) {}\n<\/pre><\/div>\n\n\n
Os records s\u00e3o imut\u00e1veis, o que os torna ideais para muitos casos de uso. Entretanto, sua natureza imut\u00e1vel tamb\u00e9m pode ser uma limita\u00e7\u00e3o em projetos que demandam mutabilidade. Para cen\u00e1rios onde mutabilidade \u00e9 necess\u00e1ria, linguagens como Groovy e Kotlin fornecem solu\u00e7\u00f5es pr\u00e1ticas e integradas diretamente ao ecossistema Java.<\/p>\n\n\n\n
Exemplo com Kotlin (data class):<\/strong><\/p>\n\n\n
\ndata class User(var name: String, var email: String)\n<\/pre><\/div>\n\n\n
Em Kotlin, os data classes<\/code> geram automaticamente getters, setters (para propriedades mut\u00e1veis), m\u00e9todos equals<\/code>, hashCode<\/code>, toString<\/code> e um copy<\/code>. Isso fornece flexibilidade e reduz a quantidade de c\u00f3digo boilerplate, sem a necessidade de bibliotecas adicionais.<\/p>\n\n\n\n
Exemplo com Groovy:<\/strong><\/p>\n\n\n
\n@Canonical\nclass User {\n    String name\n    String email\n}\n<\/pre><\/div>\n\n\n
No Groovy, os getters e setters s\u00e3o gerados implicitamente, mesmo sem anota\u00e7\u00f5es. Isso significa que o bytecode final ter\u00e1 os m\u00e9todos necess\u00e1rios de maneira transparente, similar a uma classe Java tradicional. A anota\u00e7\u00e3o @Canonical<\/code> adiciona automaticamente m\u00e9todos \u00fateis como toString<\/code>, equals<\/code> e hashCode<\/code>.<\/p>\n\n\n\n
Usando Classes Groovy e Kotlin no Java<\/h4>\n\n\n\n
Classes criadas em Groovy e Kotlin s\u00e3o completamente compat\u00edveis com c\u00f3digo Java. Por exemplo, uma classe Groovy ou Kotlin pode ser usada diretamente em um projeto Java:<\/p>\n\n\n\n
Classe Groovy:<\/strong><\/p>\n\n\n
\nUser user = new User("John Doe", "john.doe@example.com");\nuser.setName("Jane Doe");\nSystem.out.println(user.getName());\n<\/pre><\/div>\n\n\n
Classe Kotlin:<\/strong><\/p>\n\n\n
\nUser user = new User("John Doe", "john.doe@example.com");\nuser.setName("Jane Doe");\nSystem.out.println(user.getName());\n<\/pre><\/div>\n\n\n
Compatibilidade com JPA\/Hibernate e Frameworks do Ecossistema Java<\/h3>\n\n\n\n
Tanto Groovy quanto Kotlin s\u00e3o altamente compat\u00edveis com frameworks como JPA\/Hibernate, Jackson e Spring. Em Kotlin, a mutabilidade das propriedades pode ser controlada com var<\/code> e val<\/code>, permitindo modelar entidades JPA facilmente. No Groovy, o suporte a anota\u00e7\u00f5es Java padr\u00e3o facilita a integra\u00e7\u00e3o sem esfor\u00e7o adicional.<\/p>\n\n\n\n
Frameworks como Jackson tamb\u00e9m lidam bem com classes Groovy e Kotlin, devido \u00e0 gera\u00e7\u00e3o de m\u00e9todos padr\u00e3o como getters e setters. Isso garante que a serializa\u00e7\u00e3o e desserializa\u00e7\u00e3o funcionem sem a necessidade de configura\u00e7\u00f5es espec\u00edficas.<\/p>\n\n\n\n\n  <\/a>\n\n\n\n
Poss\u00edveis Problemas de Manuten\u00e7\u00e3o<\/h3>\n\n\n\n
C\u00f3digo gerado automaticamente \u00e9, muitas vezes, menos flex\u00edvel e mais propenso a criar armadilhas durante manuten\u00e7\u00f5es futuras. Por exemplo, uma altera\u00e7\u00e3o em um campo pode exigir um controle maior sobre getters e setters, algo que Lombok abstrai completamente. Nessas situa\u00e7\u00f5es, a abstra\u00e7\u00e3o fornecida por Lombok se torna mais um obst\u00e1culo do que uma vantagem.<\/p>\n\n\n\n
Al\u00e9m disso, a falta de controle granular sobre o c\u00f3digo gerado dificulta a adapta\u00e7\u00e3o do sistema a requisitos espec\u00edficos, como mudan\u00e7as em l\u00f3gica de neg\u00f3cios ou conformidade com padr\u00f5es corporativos. Em equipes grandes, isso pode levar a retrabalho e perda de efici\u00eancia.<\/p>\n\n\n\n
Problemas de Conformidade com Auditorias<\/h3>\n\n\n\n
Em organiza\u00e7\u00f5es que seguem padr\u00f5es rigorosos de auditoria, o uso de Lombok pode ser um problema. C\u00f3digo invis\u00edvel ou magicamente gerado \u00e9 mais dif\u00edcil de justificar para auditores, que preferem ver implementa\u00e7\u00f5es expl\u00edcitas para assegurar que a aplica\u00e7\u00e3o atende aos requisitos de seguran\u00e7a e conformidade.<\/p>\n\n\n\n
Al\u00e9m disso, ambientes regulados frequentemente exigem documenta\u00e7\u00e3o detalhada e previsibilidade. O uso de Lombok, com sua abordagem de “c\u00f3digo invis\u00edvel”, pode comprometer a capacidade de atender a esses requisitos, especialmente em ind\u00fastrias como finan\u00e7as e sa\u00fade.<\/p>\n\n\n\n
Conclus\u00e3o<\/h3>\n\n\n\n
Embora Lombok tenha sido uma solu\u00e7\u00e3o \u00fatil para reduzir boilerplate no passado, as mudan\u00e7as recentes no Java e as limita\u00e7\u00f5es da pr\u00f3pria biblioteca tornam seu uso menos vantajoso nos dias de hoje. A prefer\u00eancia por solu\u00e7\u00f5es nativas, maior clareza no c\u00f3digo e menor depend\u00eancia de ferramentas externas s\u00e3o tend\u00eancias que ajudam a garantir a longevidade e a manuten\u00e7\u00e3o do projeto.<\/p>\n\n\n\n
Explorar linguagens modernas como Kotlin e Groovy oferece uma alternativa poderosa para evitar a depend\u00eancia em bibliotecas externas. Al\u00e9m de reduzir o c\u00f3digo boilerplate, essas linguagens introduzem funcionalidades que enriquecem o ecossistema Java, sem sacrificar a compatibilidade com frameworks populares como JPA\/Hibernate e Jackson. Adotar pr\u00e1ticas modernas assegura sistemas mais robustos, test\u00e1veis e f\u00e1ceis de manter, alinhando-se \u00e0s exig\u00eancias de um desenvolvimento sustent\u00e1vel e escal\u00e1vel.<\/p>\n\n\n\n
Treinamentos relacionados com essa postagem<\/h2>\n\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n\n  \n<\/a>\n","protected":false},"excerpt":{"rendered":"
Project Lombok, uma biblioteca amplamente usada por desenvolvedores Java para reduzir boilerplate code, tem sido alvo de pol\u00eamicas desde o seu lan\u00e7amento. Neste texto, exploraremos as principais raz\u00f5es para evitar o uso de Lombok em projetos modernos, considerando as consequ\u00eancias de sua ado\u00e7\u00e3o e alternativas mais sustent\u00e1veis no ecossistema Java. Ao final, esperamos oferecer uma […]<\/p>\n","protected":false},"author":1,"featured_media":1869,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[366,363,379,378,380],"tags":[377,165,171,376,375],"_links":{"self":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1864"}],"collection":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1864"}],"version-history":[{"count":7,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1864\/revisions"}],"predecessor-version":[{"id":1888,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1864\/revisions\/1888"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1869"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}