Registro do getter / setter do Lombok x Java 14

10

Eu amo o projeto Lombok, mas atualmente estou lendo e testando alguns dos novos recursos do java 14.

Dentro do novo recurso, existe a palavra-chave record que permite criar uma classe com a seguinte funcionalidade incorporada: construtor, campos finais privados, acessadores, métodos iguais / hashCode, getters, toString.

Agora, minha pergunta é: é melhor contar com o recurso do Lombok ou devemos começar a usar a funcionalidade de registro:

É melhor usar isso:

record Person (String name, String surname) {}

ou aquilo:

@AllArgsConstructor
@ToString
@EqualsAndHashCode
public class GetterSetterExample {
  @Getter private int name;
  @Getter private int surname;
}

Quais são os prós e os contras das duas abordagens?

java getter lombok java-14 java-record gixlg
fonte
Por um lado, recordnão funcionará para coisas que esperam getters e setters no estilo JavaBeans.
Mark Rotteveel 19/04
2
O que o comentário de Rotteveel significa é que o método de acesso à propriedade em um registro é nomeado com o mesmo nome da propriedade. Portanto, alice.phoneNumber()em vez da convenção JavaBeans de prefixar com get, como em alice.getPhoneNumber().
Basil Bourque
11
O recordrecurso é um recurso de visualização , ainda não pronto para uso na produção.
Basil Bourque
Os registros têm muitas restrições em comparação às classes, um registro não pode estender outro registro ou classe, por exemplo, consulte a seção de restrições neste JEP openjdk.java.net/jeps/359 para obter mais detalhes
NAIT

Respostas:

9

Lombok, e o recordrecurso da linguagem Java, são ferramentas diferentes para coisas diferentes. Há alguma sobreposição superficial, mas não deixe que isso o distraia.

Lombok é amplamente sobre conveniência sintática ; é um microprocessador pré-carregado com alguns padrões úteis conhecidos de código. Não confere nenhuma semântica; apenas automatiza os padrões, de acordo com alguns botões que você define no código com anotações. Lombok é puramente sobre a conveniência de implementar classes de transporte de dados.

Registros são um recurso semântico ; são tuplas nominais . Ao fazer uma declaração semântica que Point é uma tupla (int x, int y), o compilador pode derivar sua representação, bem como os protocolos de construção, declaração, igualdade, hash e representação de string, a partir dessa descrição do estado. Como eles carregam semântica, os leitores e as estruturas também podem raciocinar com maior confiança sobre a API dos registros. (Isso também pode ser sintaticamente conveniente; se assim for, isso é ótimo.)

Brian Goetz
fonte
11
+1 Brian Goetz: E isso assumindo que você pode obter a versão atual do Lombok em seu IDE. Gostaria de saber se Lombok tem alguma vantagem significativa em relação à leitura mais rápida do código que um comentário da classe não conferiria.
Trunk
4

Também brinco com essa combinação há algum tempo e, com um pouco de prática, pude listar as seguintes diferenças:

Lombok

  • Os registros ainda não são um recurso lançado e são apenas um recurso de visualização. Portanto, ficar com Lombok faz mais sentido.
  • Eles ainda não são uma ferramenta tão poderosa para eliminar o Lombok todos juntos. Observe que a biblioteca tem muito mais a oferecer além do @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
  • Experiente por si mesmo, EqualsAndHashCodenão é o mesmo que você esperaria quando se trata de migrar para registros .

Registros

  • Em uma observação diferente, se o requisito de sua representação de objeto for um "suporte de dados", você ainda poderá obter vantagem dos Registros, sem depender de uma biblioteca adicional para reduzir o código padrão para executar isso com precisão. Essa é a razão pela qual, como uma nota conclusiva, este blog lê o seguinte:

    Também ajudará as equipes a eliminar muitas implementações codificadas manualmente do padrão subjacente e reduzir ou remover a necessidade de bibliotecas como o Lombok.

Obviamente, no dia-a-dia, é sempre sábio, com base nos requisitos de um projeto, escolher qual caminho seguir e praticar.

Naman
fonte
Nota - eu tentaria manter isso atualizado com mais exemplos de como um usuário para usar os dois com frequência no momento.
Naman
3

NB: Em vez da árvore de anotações de Natal, você pode usar apenas @Valuena classe. Observe que isso torna a aula final, e torna todos os campos privados e finais, além de fornecer todo o resto. Isso é quase o que os registros são (eles também são finais e todos os campos são finais).

recordainda está em pré-visualização, portanto, para o código de produção, obviamente ainda não é adequado. Use lombok.

Uma vez que os registros estão fora de visualização, fica mais complicado. Lombok é MUITO mais flexível; você pode facilmente trocar por algum novo aspecto sem precisar reescrever todo o código (você pode, por exemplo, adicionar uma cláusula 'extends' à sua classe sem ter que escrever manualmente os métodos equals e hashCode; algo que os registros não podem fornecer). O Lombok também oferece mais recursos: Você pode, por exemplo, adicionar um construtor adicionando a @Builderanotação; algo que os registros não podem fazer.

Se for altamente improvável, você usará isso para a classe que está criando - eu usaria registros.

AVISO LEGAL: Sou o principal colaborador do Projeto Lombok.

rzwitserloot
fonte