> An alternative approach to Lombok would be to think about how the project ended up with so many dumb data classes. Mapping entities to/from data transfer obj

> An alternative approach to Lombok would be to think about how the project ended up with so many dumb data classes. Mapping entities to/from data transfer objects is a well established technique, as using dumb POJOs to drive serialzation/deserialization. If you throw CQRS into the mix you can get a POJO/endpoint ratio that is greater than 1:1. Do you want to write bug-prone boilerplate code for all those POJOs you are forced to write? Or do you prefer to simply add lombok to the project and add a single class annotation? It's disingenuous to blindly criticize the extensive use of POJOs and DTOs as if it was code smell. In some applications it's quite the opposite. There is a ver good reason why lombok is very popular, as are other projects designed to complement it. In .NET Core land, where POCOs are used extensively, AutoMapper is also a must-have just because the need to handle POCOs without having to write all the boilerplate code is very real and pervasive.