Generator-jhipster: Lombok dependency for LoC reduction

Created on 26 Apr 2016 · 6Comments · Source: jhipster/generator-jhipster

Overview of the issue

Lombok dependency could be included in order to reduce the generated LoC and to have 'cleaner' java classes.

Motivation for or Use Case

This issue is just a suggestion since everything works fine now... Lombok allows you to annotate variables and classes in order to generate getters, setters, toString, equals and hashcode. An example:

@Getter
@Setter
private String name;

This will generate the getter and setter for the variable name ONLY in the .class... The .java file will be clean and in the variable definition itself you can see if it already has those methods.

@Getter
@Setter
public class AnyClass ...

By annotating a class, you will automatically have getters and setters for everybody.

See also: @Data, @ToString @EqualsAndHashCode
https://projectlombok.org/

JHipster Version(s)

v3.0.0

Browsers and Operating System

Chrome 49 over Windows 8.1

area area wont-fix

Source

imTachu

👍3 😄1 👎1

Most helpful comment

No problem @imTachu that was a good intention!
In more recent code I've been really annoyed by Lombok (again!) in Spring Boot classes, as IDEA sees the source code of the class doesn't match the class, so debugging is really annoying... In the end I have red stuff all over the place in my IDE... This is really more trouble than what it solves :-(

jdubois on 26 Apr 2016

👍5

All 6 comments

Does mapstruct able work with lombok?

mallim on 26 Apr 2016

I'm afraid lombok is not compatible with Java 9 : https://groups.google.com/forum/#!topic/bazel-discuss/ZRWdqJfYEPw

I also found this argument here : http://jnb.ociweb.com/jnb/jnbJan2010.html

The most common argument holds that annotations were intended for "meta" information and are not to be used in such a way that would leave the codebase unable to be compiled were they removed. This is certainly the situation with Lombok annotations. New methods result from these annotations that are intended to be used not only by a framework, but by other parts of the application. Project Lombok's development-time support is its bread and butter, but this does have consequences, not the least of which is limited IDE support.

The author of this library wrote this in Reddit a long time ago :

I'm the author of project lombok.
It's a total hack. Using non-public API. Presumptuous casting (knowing that an annotation processor running in javac will get an instance of JavacAnnotationProcessor, which is the internal implementation of AnnotationProcessor (an interface), which so happens to have a couple of extra methods that are used to get at the live AST).
On eclipse, it's arguably worse (and yet more robust) - a java agent is used to inject code into the eclipse grammar and parser class, which is of course entirely non-public API and totally off limits.
If you could do what lombok does with standard API, I would have done it that way, but you can't. Still, for what its worth, I developed the eclipse plugin for eclipse v3.5 running on java 1.6, and without making any changes it worked on eclipse v3.4 running on java 1.5 as well, so it's not completely fragile.

Cleaner is not always better if it's then harder to debug, or understand the real code executed by the JVM, without having to decompile the class. Also, the java code is no more portable without having to include the lombok dependency, and can cause confusion when sharing code.

Today, Lombok has 344 open issues, which is a lot.

I had a bad experience with an Android Library who did the same thing than lombok, and I lost a lot of time debugging edge case, so I'm very suspicious now when I see Annotation Processing to enhance the class bytecode. I'm also afraid there might be some bugs with other libraries used in JHipster, like Mapstruct, Jackson, JPA/Hibernate, Liquidbase and with the differents IDE.

Finally, it could raise a lot of false positive in SonarSource, and break continuous integration builds.

@imTachu Do you use it in a production application?