Vai usar Lombok no seu projeto Java?
Fernando Boaglio
Especialista de tecnologia CitiBank 💻 | JUG leader Java Meetup SP ☕️ | Open Source 🐧 | Autor dos livros: {Spring Boot, MongoDB, Jenkins, Play Framework} 📗
Eu usei Lombok por muito tempo nos meus projetos, mas depois de 2020, que o Java 14 implementou o record (JEP 359), comecei a questionar se realmente vale a pena.
Parei para listar alguns perrengues que o Lombok traz ou pode trazer.
Dependência Externa
O uso de Lombok adiciona uma dependência externa ao seu projeto. Em projetos onde a minimização de dependências é crucial, isso é um problema.
Compilação e IDE
Nem todas as IDEs suportam Lombok perfeitamente. Pode ser necessário instalar plugins adicionais para que a IDE reconheça e processe as anotações do Lombok corretamente. E junto disso tem a compatibilidade das diferentes versões de Lombok com as diferentes versões de IDEs.
Legibilidade e Manutenção
O código gerado pelo Lombok não é diretamente visível no código-fonte, o que dificulta a compreensão para novos desenvolvedores ou aqueles não familiarizados com a biblioteca. Isso afeta a legibilidade e a capacidade de manutenção do código.
Debug
Depurar código que utiliza Lombok é complicado, pois as anotações geram código em tempo de compilação que não está visível no código-fonte. E se o seu debug precisa olhar o que está acontecendo no equals ? Boa sorte...
Erro em Tempo de Compilação
Recomendados pelo LinkedIn
Alguns erros que seriam evidentes em tempo de compilação podem não ser detectados facilmente, pois o código gerado pelo Lombok não é visto diretamente pelo desenvolvedor.
Complexidade Adicional
Para desenvolvedores que não estão familiarizados com Lombok, a inclusão dessa ferramenta pode adicionar uma curva de aprendizado e aumentar a complexidade do projeto.
Essas desvantagens não necessariamente desqualificam o uso de Lombok, mas são pontos importantes a serem considerados ao decidir se deve ou não integrar a biblioteca em um projeto.
Mas o record tem tudo o que o Lombok tem? Certamente não, ele não tem Builder nativo, então é necessário codificar., mas ele é nativo da linguagem.
Você, desenvolvedor, precisa colocar esses prós e contras na balança para ver o que é melhor para o seu sistema.
A minha opinião é: Lombok: se puder evitar, evite.
Senior Software Engineer {Java} [Web,Mobile,Desktop,Embedded]
5 mToda vez que olho pro lombok, e quanto mais o tempo passa, vejo a demora que a Oracle demora pra evoluir a linguagem e matar os gets e sets, saporra era pra ser opcional ... Fiquei feliz com os records, pensei que ia ser isso, mas ele é muito engessado e ruim para testes.
java poderia ter um update que as classes tivessem um funcionamento parecido com os data class do kotlin, tudo mais simples e prático!
Aws Developer / Technical Lead / Java Developer / C1 advanced english level
5 mmuito desnecessário
Java Developer
5 m@RequiredArgsConstructor @Sl4j @Builder Sao bem uteis. Acho que recurso é recurso, nao precisa ser 0 e 1, usar ou nao usar. Usa quando lhe for util.
Backend senior | Java 8+ | Spring | Arch | Tests | Cloud
5 mOs famosos boilerplate, eu uso o lombok, ainda não tive projetos com a versão do Java citada, mas minha opinião é "faz sentido usar?" Até então não tive problemas com lombok, tem me atendido, mas sei que por debaixo dos panos sua utilizaçao não é das mais claras ou ajuda no debug. A questão de legibilidade, é uma obersavação a se fazer, vamos ver a annotation repository, não faz parte do lombok e sim traga pelo Spring, ela na verdade só é posta na interface por questões de boa prática, mas na verdade ela não é necessária. Mas agora pensando, posso ter tido problemas por ter usado lombok, vale a indagação se ajuda ou não ajuda. 👋