Shall we use Lombok or not?

[zhajikun]

In current IridiumIdentity JAVA code, all JAVA entity classes (POJO) were provided with Getters/Setters , making these entity classes verbose, which also increases coding effort to programmers.

Lombok is a java tool, which helps create those common methods automatically. By adding a few simple Lombok annotations, those methods such as Getters/Setters, No Arg/All Arg contructor, tostring，and equals/hashCode will be generated by Lombok.

The pros and cons of Lombok are still under debate. I listed in blew for you to discuss.

Pros:

1. Reduce the coding amount. Programmers no need to write those common methods.
2. JAVA POJO classes can be shotter and neat.

Cons: (according to the discussion online)

1. An IDE plugin are required to be installed for openning a Lombok project. (IntelliJ, Eclipse have plugins for Lombok)
2. Some generated methods are not ideal. For example: the @DaTa annotation will generate the equals/hashCode methods. However, the equals method only compare child class fields, but not super class fields.
3. Methods naming issues. Lombok will name boolean methods getXXX ( ) , whereas the conventional naming is isXXX ( )
   4. Safety issue. Somebody raised the concern of safety of Lombok. (Possibly, the @DaTa annotation generate setters/getters for every fields).

[zhajikun]

I vote for using Lombok.
When compare the pros and cons of Lombok, The pros are greater than cons. The cons can be avoided well if we use Lombok precisely.

Here are my answers to pros

Con#1 Install a plugin for Lombok. The plugin for IntelliJ and Eclipse is easy to install. They are free.

Con#2 We should NOT use @DaTa annotation at most of the POJO classes. Instead, we should use the combination of individual annotations(@getter, @Setter, @noarg ， @AllArg...). The @DaTa annotation contains all other individual annotations, but we may not need all individual annotations.
So, I suggest use individual annotations as you need. You can config some annotations as you need.
For example, you can exclude fields from Lombok's setter or getter by adding:
@getter(AccessLevel.NONE), @Setter(AccessLevel.NONE)

Con#3, The safety concern still comes from @DaTa annotation, we indeed should limit the use of @DaTa annotation, and should use individual annotation.

[zhajikun]

Another benefit of using Lombok

Lombok contains the @slf4j annotation, which replaced the Logger statement.

[joshfischer1108]

The main code base is in Java, but we are extending it out to other technologies. e.g. Javascript, Python, etc. How would this affect the experience of building out new code in these different technologies?

I see a win in being able to generate domain-level classes from a single source protocol buffers or something similar for multiple languages without needing to manually code to keep APIs in sync across languages. Could Lombok do something similar?

[zhajikun]

I briefly read the Protocol Buffers. It simply provide the "Builder" pattern for every language. Since the lombok has provided "Builder" pattern to JAVA classes, this "Builder" pattern is not new compare to lombok.

Although Protocol Buffers provide "Builder" to more than 10 languages. but I do not see the benefit of add 10 more language to Iridium project brings benefits, but in my opinion, scattered our energy. We use js/TS for frontend, and maybe use Python for test automation.

Lombok only works for JAVA. Other language has not have a similar languange helper yet. In my opinion, at this stage, we should focus on JAVA coding and polish our JAVA coding methodology (i.e rapid coding, rapid release, rapid iteration ....) .

[zhajikun]

One more benefit of using Lombok: The builder pattern.
Example:

@getter
@builder
public class Widget {
private final String name;
private final int id;
}

Use of builder pattern:
Widget testWidget = Widget.builder()
.name("foo")
.id(1)
.build();

[erzohrakhan]

Why should we not use Lombok?

1. Lombok does not work well with Hibernate entities. The three most common annotations we should avoid are @data, @EqualsAndHashCode and @toString

• @EqualsAndHashCode implementation can break HashSets (and HashMaps) behaviour under certain conditions.
• @tostring: Using this annotation with an entity class is risky because it’s possible that not all attributes are being initialized. If you set the FetchType of an association to LAZY or use the default fetching of a many-to-many association, Hibernate will try to read the association from the database. If you’re doing this within an active Hibernate Session, this will cause an additional query and slow down your application. Worse yet is if you do it without an active Hibernate Session. In that case, Hibernate throws a LazyInitializationException. An ordinary looking toString can cause needless very pricey db calls if not excluded from toString/equals etc.
• @DaTa: According to the JPA specification, all entity classes are required to have a public or protected no-argument constructor. @Data includes only @AllArgsConstructor and not @NoArgsConstructor

2. We will be dependent on Lombok for further updates; A year back there was an issue with Lombok when projects wanted to migrate to Java 16 but Lomok was not supporting it
   (Lombok is basically a compiler hack that relies on non-public APIs to work. These API were there up to Java 16; Java 17 aimed to strengthen encapsulation by further restricting access to internal APIs. This enhances security and encourages developers to use public APIs. )
   [FEATURE] Make Lombok compatible with JDK 16 projectlombok/lombok#2681

We now have records to avoid lot of boiler plate code