Registro do getter / setter do Lombok x Java 14

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?

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.)

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.

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.