É seguro usar o Projeto Lombok?[fechado]

Question

No caso de você não saber Projeto Lombok ajuda com alguns dos inconvenientes de Java com coisas como gerar getters e setters com anotações e mesmo simples JavaBean como geração com @de Dados.Ele realmente poderia me ajudar, especialmente em 50 diferentes objetos de evento onde você tem até 7 diferentes campos que precisam ser construídos e oculto com getters.Eu poderia remover quase mil linhas de código com isso.

No entanto, estou preocupado que, a longo prazo, será uma triste decisão.Flamewars vai entrar em erupção na ##Java Freenode canal quando eu a menciono, fornecendo fragmentos de código irá confundir possíveis ajudantes, as pessoas vão reclamar sobre a falta de JavaDoc, e o futuro commiters pode apenas remover tudo enfim.Eu realmente gostar de positivo, mas eu estou preocupado sobre o que é negativo.

Assim:É seguro usar a Lombok em qualquer projeto, pequeno ou grande?São os efeitos positivos que vale a pena os negativos?

Answer 1

Parece que você já decidiu que o Projeto Lombok dá-lhe técnicas significativas vantagens para a sua proposta de um novo projeto.(Para ser claro, desde o início, eu não vistas no Projeto Lombok, de uma forma ou de outra.)

Antes de utilizar o Projeto Lombok (ou qualquer outro jogo de mudança de tecnologia) em algum projeto (open source ou de outra forma), você precisará certificar-se de que o projeto da estaca titulares de concordar com isso.Isso inclui os desenvolvedores, e qualquer utilizadores (e.g.formal ou informal patrocinadores).

Você mencionar esses problemas potenciais:

Flamewars vai entrar em erupção na ##Java Freenode canal quando eu mencionar que,

É fácil.Ignorar / não participam na flamewars, ou simplesmente abster-se de mencionar Lombok.

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

Se a estratégia do projecto é a utilização de Lombok, em seguida, os possíveis ajudantes vai precisar se acostumar com isso.

as pessoas vão reclamar sobre a falta de JavaDoc

Esse é o seu problema.Ninguém em seu juízo perfeito, tenta aplicar rigidamente a sua organização do código-fonte / documentação regras para terceiros o software de fonte aberta.A equipe do projeto deve ser livre para definir o código fonte do projeto / documentação de padrões que são apropriados para a tecnologia a ser utilizada.

(ACOMPANHAMENTO - O Lombok desenvolvedores de reconhecer que não geração de javadoc comentários sintetizadas getter e setter é um problema.Se este é um grande problema para o seu projeto(s), então uma alternativa é criar e enviar um Lombok patch para resolver esse.)

e o futuro commiters pode apenas remover tudo enfim.

Que não!Se o projecto acordado estratégia é a utilização de Lombok, em seguida, commiters que gratuitamente de Lombok o código deve ser castigado, e se necessário, ter seus direitos de commit retirada.

Claro, isso pressupõe que você tem buy-in de partes interessadas ...incluindo os desenvolvedores.E ele assume que você está preparado para argumentar a sua causa, e manipular adequadamente o inevitável vozes dissidentes.

Answer 2

Comecei a usar o Lombok hoje. Até agora, eu gosto, mas uma desvantagem que não vi mencionada foi refatorar o apoio.

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

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 aula, digamos MyCompoundObject.java que têm 2 membros, ambos anotados com @Delegate, dizer myWidgets e myGadgets, quando Você ligar myCompoundObject.getThingies() de outra classe, é impossível saber se é delegar para o Widget ou Gadget Porque você não pode mais pular para a origem dentro do IDE.

O uso dos métodos de delegados do Eclipse "Gerate Eclipse fornece a mesma funcionalidade, é igualmente rápido e fornece salto de fonte. A desvantagem é que ele ago na sua fonte com código de caldeira que retiram o foco das coisas importantes.

Atualização 2 (26 de fevereiro de 13)
Depois de 5 meses, ainda estamos usando o Lombok, mas tenho outros aborrecimentos. A falta de um Getter & Setter declarado pode ser irritante nos momentos em que você está tentando se familiarizar com o novo código.

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

• Falta de javadocs. Se eu tivesse o campo, espero que o getter e o setter herdem esse javadoc através da etapa de compilação do Lombok.
• Salte para a definição do método me salta para a classe, mas não para a propriedade que gerou o getter. Este é um problema de plug -in.
• Obviamente, você não consegue definir um ponto de interrupção em um getter/setter, a menos que gerar ou codificar o método.
• Nota: Esta pesquisa de referência não é um problema, pois eu pensei que era. Você precisa usar uma perspectiva que permita a visão de esboço. Não é um problema para a maioria dos desenvolvedores. Meu problema era que estou usando mylyn que estava filtrando meu Outline Ver, então eu não vi os métodos. Falta de pesquisa de referências. Se eu quiser ver quem está ligando getDynamicCols(args...), Eu tenho que gerar ou codificar o setter para poder procurar referências.

Atualização 3 (7 de março de 13)
Aprendendo a usar as várias maneiras de fazer as coisas no eclipse, eu acho. Na verdade, você pode definir um ponto de interrupção condicional (BP) em um método gerado por LOMOM. Usando o Outline Ver, você pode clicar com o botão direito do mouse no método para Toggle Method Breakpoint. Então, quando você bate na BP, você pode usar a depuração Variables Vista para ver como o método gerado denominou os parâmetros (geralmente o mesmo que o nome do campo) e, finalmente, use o Breakpoints Vista para clicar com o botão direito do mouse no BP e selecione 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 LOMOMPK no seu Maven POM. O projeto ainda compila, mas os arquivos são sinalizados por ter erros de compilação porque não podem ver os métodos que o Lombok está criando. A limpeza do cache do NetBeans resolve o problema. Não tenho certeza se existe uma opção de "projeto limpo", como existe no Eclipse. Pequena questão, mas queria torná -lo conhecido.

Atualização 5 (17 de janeiro de 14)
Lombok nem sempre é bom com groovy, ou pelo menos o groovy-eclipse-compiler. Você pode ter que 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. O Lombok é um pouco viciante e, se você trabalha em um projeto em que não pode usá -lo por algum motivo, isso irá incomodar você. Você pode estar melhor, nunca o utiliza.

ATUALIZAÇÃO 7 (23 '14 de julho)
Esta é uma atualização interessante, porque aborda diretamente o segurança de adotar Lombok sobre o qual o OP perguntou.

A partir de v1.14, o @Delegate A anotação foi rebaixada para um status experimental. Os detalhes estão documentados em seu site (Docos de delegados de Lombok).

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

• Remova manualmente @Delegate Anotações e gerar/code o código do delegado. Isso é um pouco mais difícil se você estava usando atributos dentro da anotação.
• Delombok os arquivos que têm o @Delegate anotação e talvez adicione de volta às anotações que você deseja.
• Nunca atualize o LOMOMBOK ou mantenha um garfo (ou viva com o uso de recursos experimentais).
• Delombok todo o seu projeto e pare de usar o LOMOMPOK.

Tanto quanto eu sei, Delombok não tem a opção de remover um subconjunto de anotações; É tudo ou nada pelo menos para o contexto de um único arquivo. eu abri um ingresso para solicitar este recurso Com bandeiras de Delombok, mas eu 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 LOMOMPOK, além de um barco de outros recursos, incluindo @Delegar. Se você acha que terá dificuldade em vender a idéia para os poderes que estão, dê uma olhada no @CompileStatic ou @TypeChecked Anotação para ver se isso pode ajudar sua causa. Na verdade, O foco principal do lançamento do Groovy 2.0 foi a segurança estática.

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

Atualização 10 (17 de novembro de 15)
Isso pode não parecer diretamente relacionado à pergunta do OP, mas vale a pena compartilhar. Se você está procurando ferramentas para ajudá -lo a reduzir a quantidade de código de caldeira que você escreve, também pode conferir Google Auto - em particular Autovalor. Se você olhar para o deles conjunto de slides, a lista Lombok como uma solução possível 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 de ed - na verdade você pode, mas requer apenas um decompilador
• Os hackers do compilador são não padrão e frágeis
• "Em nossa opinião, seu código não é mais realmente java"

Não tenho certeza do quanto concordo com a avaliação deles. E, dados os contras da autovalor que estão documentados nos slides, eu ficarei com o Lombok (se o Groovy não for uma opção).

Atualização 11 (8 de fevereiro de 16)
eu descobri ROO da primavera tem algum 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 16)
Enquanto tenta apresentar justificativas para o motivo pelo qual é seguro trazer Lombok para o projeto em que estou trabalhando atualmente, encontrei um pedaço de ouro que foi adicionado com v1.14 - O Sistema de configuração! Isso significa que você pode configurar um projeto para despertar certos recursos que sua equipe considera insegura ou indesejável. Melhor ainda, ele também pode criar uma configuração específica do 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 senti que era seguro Adicione Lombok ao descanso de dados da primavera.

Atualização 14 (26 de setembro de 17)
Como apontado por @Gavenkoa Nos comentários sobre a pergunta do OPS, O suporte do compilador JDK9 ainda não está disponível (Edição #985). Também parece que não será uma correção fácil para a equipe da Lombok se locomover.

Atualização 15 (26 de março de 18)
O Lombok Changelog indica a partir de v1.16.20 "Compilar Lombok no JDK1.9 agora é possível" Apesar de #985 ainda está aberto.

Alterações para acomodar o JDK9, no entanto, exigiram algumas mudanças de ruptura; Todos isolados para alterações nos padrões de configuração. É um pouco preocupante que eles introduziram mudanças de ruptura, mas a versão apenas aumentou o número da versão "incremental" (passando de v1.16.18 para v1.16.20). Como este post era sobre a segurança, se você tivesse um yarn/npm Como o sistema de construção que atualizou automaticamente para a versão incremental mais recente, você pode estar em um despertar rude.

Atualização 16 (9 de janeiro de 19)

Parece 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, porém, isso foi referente a um aspecto de segurança é o fato de que o registro de alterações que vai de v1.18.2 a v1.18.4 lista dois itens como BREAKING CHANGE!? Não tenho certeza de como ocorre uma mudança de ruptura em uma atualização de "patch" semver. Pode ser um problema se você usar uma ferramenta que atualize automaticamente as versões de patch.

Answer 3

Vá em frente e use LOMOMPOK, você pode, se necessário http://projectlombok.org/features/delombok.html

Answer 4

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

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 verdadeiro quando você ainda está adicionando / removendo campos regularmente.

O mesmo vale para o @ToString Anotação e seus parâmetros que comunicam claramente o comportamento desejado em relação a campos incluídos / excluídos, uso de getters ou acesso de campo e wether ou não para ligar super.toString().

E novamente anotando uma aula inteira com @Getter ou @Setter(AccessLevel.NONE) (e opcionalmente substituindo todos os métodos divergentes) Fica imediatamente claro quais métodos estarão disponíveis para os campos.

Os benefícios continuam e 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 ter que descobrir isso do Javadoc ou implementações. O código reduzido apenas facilita a identificação de quaisquer implementações de método divergente.

Answer 5

Lombok é ótimo, mas ...

O Lombok quebra as regras do processamento de anotação, pois 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 existam.

O processamento da anotação é executado em uma série de rodadas. Em cada rodada, cada um recebe uma curva para correr. Se algum novo arquivo Java for encontrado após a conclusão da rodada, outra rodada começará. Dessa forma, a ordem dos processadores de anotação não importa se eles geram apenas novos arquivos. Como o Lombok não gera novos arquivos, nenhuma nova rodada é iniciada, portanto, alguns AP que dependem do código LOMOMPK não são executados conforme o esperado. Essa foi uma fonte enorme de dor para mim enquanto usava o MapStruct, e o Delombok-ing não é uma opção útil, pois destrói seus números de linha nos logs.

Acabei invadindo um script de construção para trabalhar com Lombok e Mapstruct. Mas eu quero soltar o Lombok devido ao quão hacky é - pelo menos neste projeto. Eu uso o Lombok o tempo todo em outras coisas.

Answer 6

Há de manutenção a longo prazo dos riscos.Primeiro, eu recomendo a leitura sobre como Lombok realmente funciona, por exemplo,algumas respostas de seus desenvolvedores aqui.

O site oficial também contém um lista de pontos negativos, incluindo-se esta citação de Reinier Zwitserloot:

É um total de hack.Uso não-API pública.Presunção de carcaça (saber que uma anotação processador executando em javac irá obter uma instância de JavacAnnotationProcessor, que é a implementação interna de AnnotationProcessor (uma interface), que acontece de ter um par extra métodos que são usados para obter a AST).

No eclipse, é sem dúvida o pior (e ainda mais robusto) - java agent é usado para injetar código no eclipse gramática e parser de classe, que é, naturalmente, completamente não-API pública e totalmente fora dos limites.

Se você pudesse fazer o que lombok faz com a norma API, o que eu teria feito dessa maneira, mas você não pode.Ainda, para o que vale a pena, eu desenvolvi o eclipse plugin para o eclipse v3.5 executado no java 1.6, e sem fazer quaisquer alterações trabalhou no eclipse v3.4 executado no java 1.5 como bem, então não é completamente frágil.

Como um resumo, enquanto Lombok pode poupar-lhe algum tempo de desenvolvimento, se há um não-compatível javac atualização (e.g.uma vulnerabilidade de mitigação) Lombok pode ficar preso com uma versão antiga do Java enquanto os desenvolvedores corrida para atualizar a sua utilização daqueles interno APIs.Se este é um sério risco, obviamente, depende do projeto.

Answer 7

Eu li algumas opiniões sobre o Lombok e, na verdade, eu estou usando ele em alguns projetos.

Bem, no primeiro contato com Lombok eu tinha uma má impressão.Depois de algumas semanas, eu comecei a gostar dele.Mas depois de alguns meses eu descobri um monte de pequenos problemas em usá-lo.Portanto, a minha impressão final sobre Lombok não é tão positivo.

Minhas razões para pensar dessa forma:

• IDE plugin de dependência.O IDE suporte para Lombok é através de plugins.Mesmo atuando boa ins maior parte do tempo, é sempre um refém a partir deste plugins para ser mantido em futuras versões do IDEs e até mesmo a versão de idioma (Java 10+ vai acelerar o desenvolvimento da linguagem).Por exemplo, eu tentei a actualização a partir do Intellij IDE 2017.3 para 2018.1 e eu não podia fazer isso porque há algum problema no real lombok versão do plugin e eu preciso esperar o plugin ser atualizado...Este também é um problema se você gostaria de usar uma alternativa mais IDE que não têm qualquer Lombok plugin de suporte.
• 'Encontrar usos do problema"..Usando Lombok você não vê gerado getter, setter, o construtor, o construtor de métodos e etc.Então, se você está planejando para descobrir o que estes métodos estão sendo utilizados em seu projeto pela IDE, você não pode fazer isso olhando apenas para a classe que detém essa métodos ocultos.
• Tão fácil que os desenvolvedores não se preocupam para quebrar o encapsulamento.Eu sei que ele não é realmente um problema de Lombok.Mas eu vi uma maior tendência para os desenvolvedores que não controlo mais o que métodos devem ser visíveis ou não.Assim, muitas vezes eles são apenas copiando e colando @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor anotações sem pensar quais são os métodos que a classe realmente precisa expor.
• Construtor Obsessão ©.Eu inventei esse nome (get off, Martin Fowler).Piadas à parte, o Construtor é tão fácil criar-se que mesmo quando uma classe tem apenas dois parâmetros, os desenvolvedores preferem usar @Builder em vez de construtor ou um construtor estático método.Às vezes eles até tentam criar um Construtor de dentro do Construtor de lombok, criando estranhas situações como MyClass.builder().name("Name").build().create().
• Barreiras quando refatoração.Se você estiver utilizando, por exemplo, um @AllArgsConstructor e necessário adicionar mais um parâmetro no construtor, o IDE não pode ajudá-lo a adicionar este parâmetro extra em todos os lugares (a maioria, testes) que são instanciar a classe.
• Misture Lombok com métodos concretos.Você não pode usar Lombok em todos os cenários para criar um getter/setter/etc.Então, você vai ver essas duas abordagens mistas em seu código.Você se acostumar com isso, depois de algum tempo, mas se sente como um corte na língua.

Como outra resposta, disse, se você está com raiva sobre o Java verbosidade e usar Lombok para lidar com isso, tentar Kotlin.

Answer 8

Sei que estou atrasado, mas não consigo resistir à tentação: alguém gosta de Lombok também deve dar uma olhada em Scala. Muitas boas idéias que você encontra em Lombok fazem parte da linguagem Scala.

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

Assim como um aviso: eu também gosto de java!

Answer 9

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 a configuração do ambiente de desenvolvimento para novos membros da equipe não é muito fácil e direta. Quando se tornou uma dor de cabeça, acabei de removê -lo. Mas é um bom trabalho e precisa de mais simplicidade para configurar.

Answer 10

Quando mostrei o projeto para minha equipe, o entusiasmo estava alto, então acho que você não deve ter medo da resposta da equipe.

• No que diz respeito ao ROI, é um estalo para integrar e não requer alteração de código em sua forma básica. (apenas adicionando uma única anotação à sua classe)

• E por último, se você mudar de idéia, poderá executar o Unlombok ou deixar seu IDE criar esses setters, getters e CTORS (que eu acho que ninguém perguntará assim que eles virem como seu pojo se torna claro)

Answer 11

Queria usar o Lombok's @ToString Mas logo enfrentou erros de compilação aleatória na reconstrução do projeto em Intellij Idea. Teve que acessar a compilação várias vezes antes que a compilação incremental pudesse concluir com o sucesso.

Tentei o LOMOMBOK 1.12.2 e 0.9.3 com Intellij IDEA 12.1.6 e 13.0 sem nenhum plugin LOMOMBOK no JDK 1.6.0_39 e 1.6.0_45.

Teve que copiar manualmente métodos gerados por fonte delompotada e colocar o Lombok em espera até os melhores horários.

Atualizar

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

Arquivou 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 tem mais esses problemas. Eu acho que pode ser fechado aqui.

Atualizar

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

Answer 12

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

1. Ele poluia seu código com uma camada indiretiva de sintaxe alternativa (leia @Getter, @Setter, etc. anotações). Em vez de aprender uma sintaxe alternativa para Java, eu mudaria para qualquer outro idioma que forneça lombok nativamente como sintaxe.
2. O LOMOMPOK exige o uso de um IDE suportado por LOMOMPO para trabalhar com seu código. Essa dependência introduz um risco considerável para qualquer projeto não trivial. O projeto LOMOBOK de código aberto possui recursos suficientes para continuar fornecendo suporte para diferentes versões de uma ampla gama de IDE Java disponíveis?
3. O projeto LOMOBOK de código aberto tem recursos suficientes para continuar fornecendo suporte para versões mais recentes do Java que estarão chegando no futuro?
4. Também sinto -me nervoso que o Lombok possa introduzir problemas de compatibilidade com estruturas/bibliotecas amplamente usadas (como Spring, Hibernate, Jackson, Junit, Mockito) que trabalham com seu código de byte no tempo de execução.

Ao todo, eu não preferiria "apimentar" meu java com Lombok.

Answer 13

Eu encontrei um problema com Lombok e Jackson CSV, quando eu marecionei meu objeto (Java Bean) em um arquivo CSV, colunas onde duplicado, então removi a anotação e a mareconização do @Data do Lombok funcionaram bem.

Answer 14

Eu não recomendo. Eu costumava usá -lo, mas quando trabalho com o NetBeans 7.4, estava bagunçando meus códigos. Tenho que remover o Lombok em todos os arquivos em meus projetos. Há delombok, mas como posso ter certeza de que não iria parafusar meus códigos. Eu tenho que passar dias apenas para remover o Lombok e voltar aos estilos Java comuns. Eu é muito picante ...

Answer 15

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