NB: en lugar de ese árbol de navidad de anotaciones, puede usar @Value en la clase. Tenga en cuenta que esto hace que la clase sea final, y hace que todos los campos sean privados y finales, y le da todo el resto también. Esto está cerca de lo que son los registros (ellos también son definitivos y todos los campos dentro son definitivos).

record todavía está en vista previa, por lo que para el código de producción, obviamente, aún no es adecuado. Usa lombok.

Una vez que los registros están fuera de la vista previa, es más complicado. Lombok es MUCHO más flexible; puede intercambiar fácilmente algún aspecto nuevo sin tener que volver a escribir todo el código (puede, por ejemplo, agregar una cláusula 'extiende' a su clase sin tener que escribir a mano el método equals y hashCode; algo que los registros no pueden darle). Lombok también le brinda más funciones: puede, por ejemplo, agregar un constructor agregando la anotación @Builder ; no es algo que los registros puedan hacer.

Si es muy poco probable que vaya a usar algo de eso para la clase que está diseñando, usaría registros.

DESCARGO DE RESPONSABILIDAD: Soy un colaborador principal del Proyecto Lombok.

También he estado jugando con esta combinación durante algún tiempo y con un poco de práctica podría enumerar las siguientes diferencias:

Lombok

• Los registros aún no son una herramienta tan poderosa para eliminar a Lombok por completo. Tenga en cuenta que la biblioteca tiene mucho más que ofrecer que solo @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode .
• Experimentado por uno mismo, EqualsAndHashCode no es lo mismo que cabría esperar cuando se trata de migrar a registros .

Registros

• Los registros son una parte oficial del lenguaje, con el apoyo de todos los principales IDE
• En una nota diferente, si el requisito de la representación de su objeto es ser un "portador de datos", aún puede buscar la ventaja de los Registros, sin depender de una biblioteca adicional para reducir el código repetitivo para realizar eso con precisión. Es por ello que como nota conclusiva este blog lee lo siguiente:

También ayudará a los equipos a eliminar muchas implementaciones codificadas a mano del patrón subyacente y reducir o eliminar la necesidad de bibliotecas como Lombok.

Por supuesto, en el día a día, siempre es prudente, según los requisitos de un proyecto, elegir qué camino seguir y practicar.

Lombok y la función de record del lenguaje Java son herramientas diferentes para cosas diferentes. Hay cierta superposición superficial, pero no dejes que eso te distraiga.

Lombok se trata en gran medida de la conveniencia sintáctica ; es un macroprocesador precargado con algunos patrones de código útiles conocidos. No confiere ninguna semántica; simplemente automatiza los patrones, de acuerdo con algunas perillas que configuraste en el código con anotaciones. Lombok se trata únicamente de la conveniencia de implementar clases de transporte de datos.

Los registros son una característica semántica ; son tuplas nominales . Al hacer una declaración semántica de que Point es una tupla de (int x, int y) , el compilador puede derivar su representación, así como los protocolos de construcción, declaración, igualdad, hashing y representación de cadenas, a partir de esta descripción de estado. Debido a que llevan semántica, los lectores y los marcos también pueden razonar con mayor confianza sobre la API de los registros. (Esto también puede ser sintácticamente conveniente; si es así, genial).

Java Records no requiere ninguna dependencia adicional, por lo que creo que es mejor usarlos en lugar de Lombok.

Si su proyecto es compatible con Java 14, ya puede usarlos en Eclipse.

Hay un complemento en el mercado para ello:

https://marketplace.eclipse.org/content/java-14-support-eclipse-2020-03-415

Si bien Brian explica bien los diferentes objetivos de Lombok y los registros, no explica cuándo usar cuál.

Si su clase es un "agregado de datos transparente y superficialmente inmutable", entonces un registro hará un gran trabajo porque:

1. tiene incluso menos ceremonia que una clase anotada con Lombok
2. lleva la información semántica "esta es una clase de datos inmutable" (como se enfatiza en la respuesta de Brian Goetz). Esta información semántica puede ser valiosa tanto para programadores como para frameworks.

Todavía usaría Lombok si su clase no puede vivir con las restricciones de los registros (por ejemplo, inmutabilidad, sin constructor, no extensible).

En resumen, si está haciendo codificación funcional con Java, use registros. De lo contrario, use Lombok, es mucho más flexible y potente.

Hay algunas excepciones a esta regla, por ejemplo, en la codificación API.