Hi Mati, thanks for the follow-up video. I didn't know how Lombok does the preprocessing, and I consider that to be the strongest argument here. All that thing about code transparency and 3rd party libraries don't really hold water, because almost every project out there depends on some library that might stop working some day. I still hold that switching to records we lose one of the biggest advantages of Lombok: @Builder. This might seem irrelevant when your classes have 2 or 3 fields, but when this number grows, you'll want builders.
Hi! Thanks for the comment! I think that Lombok still has really good uses and I would use it in some conditions. But for the most part I try to avoid it. Thanks for sharing your thoughts!!
No creo poder utilizarlo como reemplazo a un DTO debido a que como manejamos los campos opcionales ? Supongamo que una API me devuelve 10 parámetros. Yo puedo hacer tranquilamente un DTO con esos 10 parámetros y luego si alguno no está presente no se definirá (en conjunto con jackson), pero con los Records (que tienen por defecto campos finales) cómo haríamos ? Si solo vienen 4 de 10 parámetros en mi Record.
I don't understand one thing. I know that we use getters and setters for controlled access, we can put custome checks inside the functions. But using Lombok defeats the purpose because there is only one validation annotation like @NonNull. We will have to write the custome methods anyways.
To be completely honest, since I’ve been doing a lot more functional programming, I don’t really care for accessor methods. I’d rather be able to access all of the properties directly. What you say makes sense. Having controlled access to properties makes the usage of Lombok unnecessary. Thanks for commenting and sharing your thoughts.
Hi. Basically, if you annotate the method that throws a checked exception with the annotation @SneakyThrows, it will turn the checked exception into an unchecked exception
