É seguro usar o Project Lombok? [fechadas]

Caso você não saiba, o Project Lombok ajuda com alguns dos aborrecimentos do Java em coisas como gerar getters e setters com anotações e até JavaBean simples como a geração com @Data . Isso realmente poderia me ajudar, especialmente em 50 objetos de eventos diferentes, onde você tem até 7 campos diferentes que precisam ser construídos e ocultados com getters. Eu poderia remover quase mil linhas de código com isso.

No entanto, estou preocupado que, a longo prazo, seja uma decisão lamentável. Flamewars entrarão em erupção no ##Java Freenodecanal quando eu o mencionar, fornecer trechos de código confundirá possíveis ajudantes, as pessoas reclamarão da falta do JavaDoc e os futuros comprometedores poderão remover tudo de qualquer maneira. Eu realmente apreciaria o positivo, mas estou preocupado com o negativo.

Portanto: é seguro usar o Lombok em qualquer projeto, pequeno ou grande? Os efeitos positivos valem os negativos?

Parece que você já decidiu que o Projeto Lombok oferece vantagens técnicas significativas para o novo projeto proposto. (Para ser claro desde o início, não tenho opiniões particulares sobre o Projeto Lombok, de um jeito ou de outro.)

Antes de usar o Projeto Lombok (ou qualquer outra tecnologia de mudança de jogo) em algum projeto (código aberto ou outro modo), você precisa garantir que os interessados ​​do projeto concordem com isso. Isso inclui os desenvolvedores e quaisquer usuários importantes (por exemplo, patrocinadores formais ou informais).

Você mencionou estes possíveis problemas:

Flamewars entrarão em erupção no canal ## Java Freenode quando eu mencionar,

Fácil. Ignore / não participe das guerras de chamas, ou simplesmente evite mencionar Lombok.

fornecer trechos de código confundirá possíveis ajudantes,

Se a estratégia do projeto for usar o Lombok, os possíveis auxiliares precisarão se acostumar.

as pessoas vão reclamar da falta do JavaDoc,

Esse é o problema deles. Ninguém em sã consciência tenta aplicar rigidamente as regras de código-fonte / documentação de sua organização a softwares de código aberto de terceiros. A equipe do projeto deve estar livre para definir os padrões de código-fonte / documentação do projeto que são apropriados para a tecnologia que está sendo usada.

( SEGUIMENTO - Os desenvolvedores do Lombok reconhecem que não é possível gerar comentários javadoc para os métodos getter e setter sintetizados. Se esse é um problema grave para o seu projeto, uma alternativa é criar e enviar um patch do Lombok para resolver isso. )

e futuros comprometedores podem remover tudo de qualquer maneira.

Isso não está ligado! Se a estratégia do projeto acordado for usar o Lombok, os participantes que retirarem o Lombok gratuitamente do código devem ser castigados e, se necessário, seus direitos de consolidação serão retirados.

Obviamente, isso pressupõe que você tenha o apoio das partes interessadas ... incluindo os desenvolvedores. E pressupõe que você esteja preparado para discutir sua causa e lidar adequadamente com as inevitáveis ​​vozes dissidentes.

Comecei a usar o Lombok hoje. Até agora, eu gostei, mas uma desvantagem que não vi mencionada foi a refatoração do suporte.

Se você tiver uma classe anotada @Data, ela gerará os getters e setters para você com base nos nomes dos campos. Se você usar um desses getters em outra classe e decidir que o campo tem um nome incorreto, ele não encontrará usos desses getters e setters e substituirá o nome antigo pelo novo.

Eu imagino que isso teria que ser feito através de um plug-in IDE e não via Lombok.

ATUALIZAÇÃO (22 de janeiro de 13)
Depois de usar o Lombok por 3 meses, eu ainda o recomendo para a maioria dos projetos. No entanto, encontrei outra desvantagem semelhante à listada acima.

Se você tem uma turma, digamos MyCompoundObject.javaque tenha 2 membros, ambos anotados com @Delegate, digamos myWidgetse myGadgets, quando você liga myCompoundObject.getThingies()de outra turma, é impossível saber se está delegando Widgetou Gadgetporque não é mais possível ir para a origem no IDE.

O uso do Eclipse "Gerar Métodos de Delegação ..." fornece a mesma funcionalidade, é tão rápido quanto fornece salto de origem. A desvantagem é que ela atrapalha sua fonte com um código padronizado que tira o foco das coisas importantes.

ATUALIZAÇÃO 2 (26 de fevereiro de 13)
Após 5 meses, ainda estamos usando o Lombok, mas tenho outros aborrecimentos. A falta de um getter & setter declarado pode ser irritante às vezes quando você está tentando se familiarizar com o novo código.

Por exemplo, se eu getDynamicCols()vir um método chamado, mas não souber do que se trata, tenho alguns obstáculos extras a serem resolvidos para determinar o objetivo desse método. Alguns dos obstáculos são Lombok, outros são a falta de um plug-in inteligente Lombok. Os obstáculos incluem:

• Falta de JavaDocs. Se eu javadoc o campo, espero que o getter e o setter herdem esse javadoc através da etapa de compilação do Lombok.
• Ir para a definição de método me leva para a classe, mas não para a propriedade que gerou o getter. Este é um problema de plug-in.
• Obviamente, você não pode definir um ponto de interrupção em um getter / setter, a menos que gere ou codifique o método.
• NOTA: Esta pesquisa de referência não é um problema como eu pensava. Você precisa usar uma perspectiva que ative a exibição de estrutura de tópicos. Não é um problema para a maioria dos desenvolvedores. Meu problema era que eu estava usando o Mylyn, que estava filtrando minha Outlineexibição, então não vi os métodos. Pesquisa de falta de referências. Se eu quiser ver quem está ligando getDynamicCols(args...), preciso gerar ou codificar o configurador para poder procurar referências.

ATUALIZAÇÃO 3 (7 de março de 13)
Acho que aprendi a usar as várias maneiras de fazer as coisas no Eclipse. Você pode realmente definir um ponto de interrupção condicional (BP) em um método gerado pelo Lombok. Usando a Outlinevisualização, você pode clicar com o botão direito do mouse no método para Toggle Method Breakpoint. Então, quando você atinge o BP, pode usar a Variablesvisualização de depuração para ver como o método gerado nomeou os parâmetros (geralmente o mesmo que o nome do campo) e, finalmente, usar a Breakpointsvisualização para clicar com o botão direito do mouse no BP e selecionar Breakpoint Properties...para adicionar uma condição. Agradável.

ATUALIZAÇÃO 4 (16 de agosto de 13) O
Netbeans não gosta quando você atualiza suas dependências do Lombok no seu pom do Maven. O projeto ainda é compilado, mas os arquivos são sinalizados por terem erros de compilação porque não podem ver os métodos que o Lombok está criando. Limpar o cache do Netbeans resolve o problema. Não tenho certeza se existe uma opção "Limpar projeto", como existe no Eclipse. Problema menor, mas queria torná-lo conhecido.

ATUALIZAÇÃO 5 (17 / jan / 14)
Lombok nem sempre é legal com Groovy, ou pelo menos com o groovy-eclipse-compiler. Talvez você precise fazer o downgrade da sua versão do compilador. Maven Groovy e Java + Lombok

ATUALIZAÇÃO 6 (26 de junho de 14)
Uma palavra de aviso. Lombok é um pouco viciante e se você trabalha em um projeto em que não pode usá-lo por algum motivo, isso o irritará. Você pode estar melhor só de nunca usá-lo.

ATUALIZAÇÃO 7 (23 de julho de 14)
Esta é uma atualização um pouco interessante, pois aborda diretamente a segurança da adoção do Lombok que o OP perguntou.

A partir da v1.14, a @Delegateanotação foi rebaixada para um status Experimental. Os detalhes estão documentados em seu site ( Documentos do Delegado Lombok ).

O problema é que, se você estava usando esse recurso, suas opções de recuperação são limitadas. Vejo as opções como:

• Remova manualmente as @Delegateanotações e gere / codifique manualmente o código delegado. Isso é um pouco mais difícil se você estiver usando atributos na anotação.
• Descompacte os arquivos que possuem a @Delegateanotação e talvez adicione novamente as anotações que você deseja.
• Nunca atualize o Lombok ou mantenha um garfo (ou convide com o uso de recursos experimentais).
• Delombok todo o seu projeto e pare de usar Lombok.

Pelo que sei, Delombok não tem uma opção para remover um subconjunto de anotações ; é tudo ou nada pelo menos para o contexto de um único arquivo. Abri um ticket para solicitar esse recurso com sinalizadores Delombok, mas não esperaria isso no futuro próximo.

ATUALIZAÇÃO 8 (20 de outubro de 14)
Se for uma opção para você, o Groovy oferece a maioria dos mesmos benefícios do Lombok, além de uma carga de outros recursos, incluindo o @Delegate . Se você acha que vai ter dificuldade em vender a ideia para os poderes que existem, dê uma olhada na anotação @CompileStaticou @TypeCheckedpara ver se isso pode ajudar sua causa. De fato, o foco principal da versão Groovy 2.0 era a segurança estática .

ATUALIZAÇÃO 9 (1º de setembro de 15) O
Lombok ainda está sendo mantido e aprimorado ativamente , o que é um bom presságio para o nível de segurança da adoção. As anotações do @Builder são um dos meus novos recursos favoritos.

ATUALIZAÇÃO 10 (17/11/15)
Isso pode não parecer diretamente relacionado à pergunta do OP, mas vale a pena compartilhar. Se você estiver procurando por ferramentas para ajudar a reduzir a quantidade de código padrão que você escreve, também pode conferir o Google Auto - em particular o AutoValue . Se você observar o deck de slides , a lista Lombok é uma possível solução para o problema que eles estão tentando resolver. Os contras que eles listam para Lombok são:

• O código inserido é invisível (você não pode "ver" os métodos que ele gera) [nota editada - na verdade você pode, mas requer apenas um descompilador]
• Os hacks do compilador não são padrão e são frágeis
• "Na nossa opinião, seu código não é mais realmente Java"

Não sei ao certo quanto concordo com a avaliação deles. E, considerando os contras do AutoValue que estão documentados nos slides, eu continuarei aderindo ao Lombok (se o Groovy não for uma opção).

ATUALIZAÇÃO 11 (8 de fevereiro de 16)
Descobri que o Spring Roo tem algumas anotações semelhantes . Fiquei um pouco surpreso ao descobrir que Roo ainda é uma coisa e encontrar documentação para as anotações é um pouco difícil. A remoção também não parece tão fácil quanto o de-lombok. Lombok parece ser a escolha mais segura.

ATUALIZAÇÃO 12 (17 de fevereiro de 1616)
Enquanto tentava apresentar justificativas sobre por que é seguro trazer Lombok para o projeto em que estou trabalhando, encontrei uma peça de ouro que foi adicionada com v1.14- O sistema de configuração ! Isso significa que você pode configurar um projeto para desabilitar certos recursos que sua equipe considera inseguros ou indesejáveis. Melhor ainda, ele também pode criar configurações específicas de diretório com diferentes configurações. Isso é incrível.

ATUALIZAÇÃO 13 (4 de outubro de 16)
Se esse tipo de coisa importa para você, Oliver Gierke achou que era seguro adicionar Lombok ao Spring Data Rest .

ATUALIZAÇÃO 14 (26 de setembro de 17)
Como apontado por @gavenkoa nos comentários sobre a questão dos OPs, o suporte ao compilador JDK9 ainda não está disponível (edição nº 985). Também parece que não será uma solução fácil para a equipe de Lombok se locomover.

ATUALIZAÇÃO 15 (26 de março de 1818)
O registro de alterações do Lombok indica a partir da v1.16.20 " Compilar lombok no JDK1.9 agora é possível ", mesmo que o # 985 ainda esteja aberto.

As alterações para acomodar o JDK9, no entanto, exigiram algumas alterações recentes; tudo isolado para alterações nos padrões de configuração. É um pouco preocupante que eles tenham introduzido mudanças de última hora, mas a versão apenas aumentou o número da versão "Incremental" (passando da v1.16.18 para a v1.16.20). Como esta postagem tratava da segurança, se você tivesse um yarn/npmsistema de compilação semelhante que atualizasse automaticamente para a versão incremental mais recente, você pode ter um despertar rude.

ATUALIZAÇÃO 16 (9 / jan / 19)

Parece que os problemas do JDK9 foram resolvidos e o Lombok trabalha com o JDK10 e até o JDK11, tanto quanto eu sei.

Uma coisa que notei, no entanto, era preocupante do ponto de vista da segurança: o fato de o registro de alterações passar da v1.18.2 para a v1.18.4 lista dois itens como BREAKING CHANGE!? Não sei ao certo como acontece uma alteração de quebra em uma atualização de "patch" semver. Pode ser um problema se você usar uma ferramenta que atualize automaticamente as versões do patch.

Vá em frente e use o Lombok. Se necessário, você pode "delombok" seu código posteriormente http://projectlombok.org/features/delombok.html

Pessoalmente (e, portanto, subjetivamente), descobri que o uso do Lombok torna meu código mais expressivo sobre o que estou tentando obter quando comparado às implementações IDE / próprias de métodos intrincados, como hashcode & equals.

Ao usar

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

é muito mais fácil manter o Equals & HashCode consistente e acompanhar quais campos são avaliados, do que qualquer implementação IDE / própria. Isso é especialmente verdade quando você ainda está adicionando / removendo campos regularmente.

O mesmo vale para a @ToStringanotação e seus parâmetros que comunicam claramente o comportamento desejado em relação aos campos incluídos / excluídos, uso de getters ou acesso a campos e se deseja ou não chamar super.toString().

E, novamente, anotando uma classe inteira com @Getterou @Setter(AccessLevel.NONE)(e, opcionalmente, substituindo quaisquer métodos divergentes), fica imediatamente claro quais métodos estarão disponíveis para os campos.

Os benefícios continuam ...

Na minha opinião, não se trata de reduzir o código, mas de comunicar claramente o que você deseja alcançar, em vez de precisar descobrir a partir do Javadoc ou das implementações. O código reduzido facilita a identificação de implementações de métodos divergentes.

Lombok é ótimo, mas ...

Lombok quebra as regras do processamento de anotações, na medida em que não gera novos arquivos de origem. Isso significa que ele não pode ser usado com outros processadores de anotação se eles esperam que os getters / setters ou qualquer outra coisa exista.

O processamento de anotações é executado em uma série de rodadas. Em cada rodada, cada um tem uma chance de correr. Se qualquer novo arquivo java for encontrado após a conclusão da rodada, outra rodada será iniciada. Dessa forma, a ordem dos processadores de anotação não importa se eles apenas geram novos arquivos. Como o lombok não gera nenhum arquivo novo, nenhuma rodada é iniciada; portanto, alguns AP que dependem do código do lombok não são executados conforme o esperado. Essa foi uma enorme fonte de dor para mim ao usar o mapstruct, e delombok-ing não é uma opção útil, pois destrói seus números de linha nos logs.

Acabei hackeando um script de construção para trabalhar com o lombok e o mapstruct. Mas eu quero largar o lombok devido ao quão hacky é - neste projeto, pelo menos. Eu uso o lombok o tempo todo em outras coisas.

Li algumas opiniões sobre o Lombok e, na verdade, estou usando-o em alguns projetos.

Bem, no primeiro contato com Lombok, tive uma má impressão. Depois de algumas semanas, comecei a gostar. Mas depois de alguns meses, eu descobri muitos problemas pequenos usando-o. Portanto, minha impressão final sobre Lombok não é tão positiva.

Minhas razões para pensar desta maneira:

• Dependência do plugin IDE . O suporte do IDE ao Lombok é através de plugins. Mesmo trabalhando bem na maior parte do tempo, você é sempre refém desses plugins a serem mantidos nas versões futuras dos IDEs e até na versão da linguagem (o Java 10+ acelerará o desenvolvimento da linguagem). Por exemplo, tentei atualizar do Intellij IDEA 2017.3 para 2018.1 e não pude fazer isso porque havia algum problema na versão real do plug-in lombok e precisava aguardar a atualização do plug-in ... Isso também é um problema se você gostaria de usar um IDE mais alternativo que não tenha suporte para plugins Lombok.
• Problema "Encontrar usos". . Usando o Lombok, você não vê os métodos getter, setter, construtor, construtor e etc. gerados. Portanto, se você planeja descobrir onde esses métodos estão sendo usados ​​no seu projeto pelo seu IDE, não é possível fazer isso apenas procurando para a classe que possui esses métodos ocultos.
• Tão fácil que os desenvolvedores não se importam em quebrar o encapsulamento . Eu sei que não é realmente um problema de Lombok. Mas vi uma tendência maior dos desenvolvedores de não controlar mais quais métodos precisam ser visíveis ou não. Portanto, muitas vezes eles estão apenas copiando e colando @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructoranotações, sem pensar em quais métodos a classe realmente precisa ser exposta.
• Obssessão do Construtor ©. Eu inventei esse nome (desça, Martin Fowler). Brincadeiras à parte, um Construtor é tão fácil de criar que, mesmo quando uma classe tem apenas dois parâmetros, os desenvolvedores preferem usar em @Buildervez do construtor ou de um método estático do construtor. Às vezes, eles até tentam criar um Builder dentro do lombok Builder, criando situações estranhas como MyClass.builder().name("Name").build().create().
• Barreiras ao refatorar . Se você estiver usando, por exemplo, a @AllArgsConstructore precisar adicionar mais um parâmetro no construtor, o IDE não poderá ajudá-lo a adicionar esse parâmetro extra em todos os locais (principalmente testes) que estão instanciando a classe.
• Misturando Lombok com métodos concretos . Você não pode usar o Lombok em todos os cenários para criar um getter / setter / etc. Então, você verá essas duas abordagens misturadas no seu código. Você se acostuma com isso depois de algum tempo, mas parece um hack no idioma.

Como outra resposta, se você está zangado com a verbosidade do Java e usa o Lombok para lidar com isso, tente o Kotlin.

Também existem riscos de manutenção a longo prazo. Primeiro, eu recomendo a leitura sobre como o Lombok realmente funciona, por exemplo, algumas respostas de seus desenvolvedores aqui .

O site oficial também contém uma lista de desvantagens , incluindo esta citação de Reinier Zwitserloot:

É um hack total. Usando API não pública. Conversão presunçosa (sabendo que um processador de anotação em execução no javac obterá uma instância do JavacAnnotationProcessor, que é a implementação interna do AnnotationProcessor (uma interface), que possui alguns métodos extras usados ​​para acessar o AST ao vivo) .

No eclipse, é sem dúvida pior (e ainda mais robusto) - um agente java é usado para injetar código na classe gramática e analisador do eclipse, que é obviamente uma API totalmente não pública e totalmente fora dos limites.

Se você pudesse fazer o que o lombok faz com a API padrão, eu teria feito dessa maneira, mas você não pode. Ainda assim, para o que vale a pena, desenvolvi o plug-in do eclipse para o eclipse v3.5 executando no java 1.6 e, sem fazer nenhuma alteração, ele funcionou no eclipse v3.4 executando no java 1.5 também, para que não seja completamente frágil.

Como um resumo, embora o Lombok possa economizar algum tempo de desenvolvimento, se houver uma atualização de javac não compatível com versões anteriores (por exemplo, uma atenuação de vulnerabilidades), o Lombok pode ficar preso a uma versão antiga do Java enquanto os desenvolvedores se esforçam para atualizar o uso dessas APIs internas. Se esse é um risco sério, obviamente depende do projeto.

Sei que estou atrasado, mas não consigo resistir à tentação: quem gosta de Lombok também deve dar uma olhada em Scala. Muitas boas idéias encontradas em Lombok fazem parte do idioma Scala.

Na sua pergunta: é definitivamente mais fácil fazer com que seus desenvolvedores experimentem o Lombok do que o Scala. Experimente e se eles gostarem, tente Scala.

Apenas como um aviso: eu também gosto de Java!

Eu usei o Lombok em quase todos os meus projetos por um ano, mas infelizmente o removi. No começo, era uma maneira muito limpa de desenvolvimento, mas configurar o ambiente de desenvolvimento para novos membros da equipe não é muito fácil e direto. Quando se tornou uma dor de cabeça, acabei de removê-lo. Mas é um bom trabalho e precisa de mais simplicidade para configurar.

Quando mostrei o projeto à minha equipe, o entusiasmo foi alto; acho que você não deve ter medo da resposta da equipe.

• Quanto ao ROI, é fácil integrar e não requer alteração de código em sua forma básica. (apenas adicionando uma única anotação à sua turma)

• E por último, se você mudar de idéia, poderá executar o unlombok ou deixar seu IDE criar esses setters, getters e ctors (o que eu acho que ninguém vai pedir depois que eles perceberem como seu pojo fica claro)

Minha opinião sobre o Lombok é que ele apenas fornece atalhos para escrever código Java bolilerplate.
Quando se trata de usar atalhos para escrever código Java bolilerplate, eu confiaria nos recursos fornecidos pelo IDE - como no Eclipse, podemos ir ao menu Fonte> Gerar Getters e Setters para gerar getters e setters.
Eu não confiaria em uma biblioteca como Lombok para isso:

1. Ele polui o seu código com uma camada de indireção de sintaxe alternativa (leia-se @Getter, @Setteretc. anotações). Em vez de aprender uma sintaxe alternativa para Java, eu mudaria para qualquer outra linguagem que fornece nativamente Lombok como sintaxe.
2. O Lombok requer o uso de um IDE suportado pelo Lombok para trabalhar com seu código. Essa dependência apresenta um risco considerável para qualquer projeto não trivial. O projeto Lombok de código aberto tem recursos suficientes para continuar fornecendo suporte para diferentes versões de uma ampla variedade de IDEs Java disponíveis?
3. O projeto Lombok de código aberto tem recursos suficientes para continuar fornecendo suporte para versões mais recentes do Java que virão no futuro?
4. Também me sinto nervoso porque Lombok pode apresentar problemas de compatibilidade com estruturas / bibliotecas amplamente usadas (como Spring, Hibernate, Jackson, JUnit, Mockito) que funcionam com seu código de bytes em tempo de execução.

No geral, eu não preferiria "apimentar" meu Java com o Lombok.

Queria usar o lombok, @ToStringmas logo enfrentou erros aleatórios de compilação na reconstrução do projeto no Intellij IDEA. Teve que executar a compilação várias vezes antes que a compilação incremental pudesse ser concluída com êxito.

Tentei o lombok 1.12.2 e o 0.9.3 com o Intellij IDEA 12.1.6 e 13.0 sem nenhum plugin do lombok no jdk 1.6.0_39 e 1.6.0_45.

Tive que copiar manualmente os métodos gerados da fonte delomboked e colocar o lombok em espera até melhores tempos.

Atualizar

O problema ocorre apenas com a compilação paralela ativada.

Arquivado um problema: https://github.com/rzwitserloot/lombok/issues/648

Atualizar

mplushnikov comentou em 30 de janeiro de 2016:

A versão mais recente do Intellij não possui mais esses problemas. Eu acho que pode ser fechado aqui.

Atualizar

Eu recomendo mudar do Java + Lombok para o Kotlin, se possível. Como ele resolveu desde o início todos os problemas de Java que o Lombok tenta solucionar.

Encontrei um problema com o CSV do Lombok e Jackson , quando empacotou meu objeto (java bean) em um arquivo CSV, colunas duplicadas, depois removi a anotação @Data do Lombok e a marshalização funcionou bem.

Não recomendo. Eu costumava usá-lo, mas quando eu trabalhava com o NetBeans 7.4 estava mexendo nos meus códigos. Eu tenho que remover o lombok em todos os arquivos em meus projetos. Há delombok, mas como posso ter certeza de que não estragaria meus códigos. Eu tenho que passar dias apenas para remover o lombok e voltar aos estilos Java comuns. Eu apenas muito picante ...

Ainda não tentei usar o Lombok - ele é / foi o próximo na minha lista, mas parece que o Java 8 causou problemas significativos e o trabalho de correção ainda estava em andamento há uma semana. Minha fonte para isso é https://code.google.com/p/projectlombok/issues/detail?id=451 .