Java and Lombok

If you are an Indonesian, it's pretty easy to make a connection between Java and Lombok. However, this post is not about that Java and Lombok, but rather for the Java programming language and Project Lombok.

One of the drawback of Java language is its verbosity. One very easy example can be found in any typical Java POJO.

public class Order{

  private long id;
  private String name;
  private int size;

  public Order(){
  }

  public Order(long id){
    this.id = id;
  }

  public long getId(){
    return id;
  }

  public void setId(long id){
    this.id = id;
  }

  public String getName(){
    return name;
  }

  public void setName(String name){
    this.name = name;
  }

  public int getSize(){
    return size();
  }

  public void setSize(int size){
    this.size = size;
  }

  @Override
  public String toString(){
    return String.format("%s %d %d", id, name, size);
  }
}

Already that much code just for a very simple structure with constructors, getters, setters, and toString method. This is where Lombok comes to save the day! Instead of writing that much code, you can have something like this:

@Data
public class Order{

  private long id;
  private String name;
  private int size;
}

...and that's it! A clean, nice code that is easy to maintain. The @Data annotation will tell Lombok to generate the constructor, getters and setters, toString method (and even equals and hashCode method!) all during compilation time! (instead of hiding the code in other file ala AspectJ). Since Lombok can be integrated with your IDE, you will not lose the nice content assist or any other feature that you currently enjoying.

There are several other features provided by Lombok (see: Lombok features), although personally for me, this one is going to be the one I use the most. I am not too scared of introducing Lombok dependency to my project since Lombok itself presented a nice way to stop using Lombok dependency with a tool called "delombok". By using delombok, all magically generated code will be written to the source code and the dependency to Lombok library will be removed.

The only drawback I can think of is whenever I rename one of the field name and the rest of code which refer to the getter/setter will also need to be updated manually (instead of having them automatically updated using a refactor tool in your IDE), but it is a very small price to pay (I guess).