That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain.

Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like:

  @Data
  public class something {
    String name;
    int age;
  }

Lombok generates:

  public String getName() { ... }
  public void setName(String name) { ... }
  public int getAge() { ... }
  public void setAge(int age) { ... }
  public boolean equals(Something other) { ... }
  public int hashcode() { ... }
  public String toString() { ... }

I believe a similar argument could be made against using any 3rd party library. At some point who ever is maintaining your code will have to understand its dependencies at some level.

For lombok specifically, other languages have these types of features built in which of course people need to learn in order to use it.

I agree it isn't a perfect solution, but java is in dire need of boilerplate reduction features like this and lombok fills this need well.

Lombok is a bad idea, IMO.

Getters and Setters are verbose, but usually model classes are contained in a single class anyway, and can be generated automatically with any IDE. I can glance at a typical bean and ignore the code bloat without any problem.

The real issue is that Lombok generated classes don't play well with the dozens of libraries that expect Java bean style methods for auto marshaling and serialization: json generators, commons bean utils, binding libs, etc.

The savings aren't worth the trouble.