[smoyer]

If you want less typing, then you definitely want Lombok (https://projectlombok.org/). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok).

  public class something(String name, int age) {
    ...
  }

[ap22213]

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

[smoyer]

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() { ... }

[markelliot]

It might be worth a look at Immutables (http://immutables.github.io/) or FreeBuilder (https://github.com/google/FreeBuilder), both of which also use Java's built-in annotation processors to do code generation, but involve slightly less magic and produce generated classes which are not overwriting the original class.

[marktangotango]

The real win is when you do Effective Java chapter 1 immutable objects with @Builder. I worked at a Big Dumb corp that eschewed lombok, and required full test coverage of getter, setters, builders, toString, equals, and hash mehtods, and 100% javadoc coverage for all methods (even private methods). It was insanity, and carpal tunnel inducing. Lombok would have reduced the workload by 90%.

[smoyer]

Yes! ... And there are a lot of stages between a fully immutable object @Value and @Data (described above). The @Builder is so much better than most but you can also easily create a POJO with a portion of its fields immutable too (a combination of @NonNull, @Getter, @Setter and @RequiredArgsConstructor).

[cs02rm0]

One of the nice aspects of it is that if you have, say, a setter method which does something slightly unusual (e.g. setLastName does a call to setName(getFirstName() + " " +lastName) - unlikely example perhaps) then it stands out from the crowd of otherwise straightforward getters and setters.

[skoczymroczny]

But then you switch to JavaFX and you realize Lombok won't help you with JavaFX properties generation :(

[jay-anderson]

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.

[grogenaut]

if you want somthing that will send people over the edge and let you cackle with glee...

https://projectlombok.org/features/val.html

I've been doing C# for while... soo nice to have this. Coming back to java was like "why am I repeating myself". They already did the diamond operator on the right hand side, this makes the left just as nice.

now let the flames begin!!!

Oh also found a use for SneakyThrows today... I'm bootstrapping a test server in my unit test, where all of the code and interfaces are designed for safety and no-crash... and this lets me short circuit right out of it when something bad happens, which in a test setup is what I want.

[hiram112]

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.

[potatosareok]

What problems do you have? Lombok does bytecode generation, I've never had a problem using it with things such as Jackson. How would an external library even know when the bytecode looks the same? I'm entirely aware I might be missing something obvious, this is a genuine question.

You can argue against Lombok for other reasons but was wondering about this specific one.