Why not use lombok?
imduffy15 opened this issue · comments
The domain classes have a lot of getters/setters. Why not use lombok? http://projectlombok.org/
+1
We are not using Lombok because:
- it has already caused far too many bugs (I'm personally fed up with this project, that has made me lose so much time)
- generating getters/setters is trivial with an IDE, so it doesn't really add much value
@jdubois -
It sounds like you've had very bad experiences with Lombok, but it would greatly reduce the code complexity that currently exists for entities; as well as improve logging capabilities. I'll be the first to admit that Lombok has, in the past, caused problems for people; especially when not using a proper build system.
Currently, however, the major IDEs have plugins for it (IntelliJ IDEA, NetBeans, Eclipse); and both maven and gradle have approaches that essentially insure there will not be build failures. Since Lombok is on a compile-time, not run time, dependency, there should be no deployment related issues.
To be specific, it would allow for/automate:
- dropping the toString and equals functions from Entities (via the @DaTa annotation)
- dropping all getters/setters from Entities and other generated classes
- Generation of a log object for each class (via the @slf4j annotation)
- Wrap all log calls with checks for the current log level
- Allow for the use of the builder pattern on Entities (via the @builder annotation)
This is a huge amount of functionality that be gained at little cost; and that would greatly simplify the boilerplate code, making it easier for developers to work on the meat of their application.
I guess I'd really like to see a community discussion of the costs/benefits, rather than just a "I don't like that because I had problems with it" response.
I use lombok in my jhipster based project too - but as you wrote - there are exists IDE plugins to easily use it. In the IntelliJ plug-in there is an option in the refactoring menu "lombok" - that will automatically converts the JHipster's generated entity class to a "lombok entity class" - you need only one click per entity.
A lot of developer will not prefer specific libs (like lombok) - everybody has it's own needs, but it's impossible, that the JHipster can meet all of expectations.
@cselti - I wasn't aware of the functionality in the plugin - that's awesome!
It addresses some of the advantages I listed, but mainly the getter/setter stuff, I would imagine; which I consider the least of the advantages.
OK, let me put it one more time: this has caused me too many bugs. Let me tell you my past experiences with Lombok, as this is the root of the issue.
- On one project, a new version of the Lombok plugin caused the IDE to crash (I think this was Intellij). So nobody could work anymore.
- On another project, Lombok made the CI server crash (and would have probably caused the production server to crash), as it triggered a bug in the JVM
- On a third project, we achieved 30% performance increase by recoding the equals/hashcode from Lombok
-> In those 3 projects, some developer gained 5 minutes, and I spent hours recoding everything. So yes, a bad experience.
Then, for JHipster, the story is also that we can't ask people to install a plugin on their IDE:
- 1st goal is to have a smooth experience: you generate the app and it works in your IDE, by default
- 2nd goal is that you can use whatever IDE you want. And some people have very exotic things, for example I just tried https://codenvy.com/ -> no plugin for this one, of course
@jdubois thanks for sharing your experiences. I think I'll avoid lombok myself.
Oh, and I just got 2 more:
- Lombok crashing with MapStruct
- Lombok making Jacoco fails, which meant the project didn't pass the Sonar quality gate
Currently [1] MapStruct 1.2.0.Final works with Lombok.
[1] http://mapstruct.org/faq/#Can-I-use-MapStruct-together-with-Project-Lombok
Yeah, and I got 2 more:
- it fails with JDK 10
- It fails with Jackson (see http://www.akazlou.com/posts/2018-02-08-journey-spring-boot-upgrade.html )
Consultants have probably bought whole houses configuring and then removing Lombok.
I can add it doesn't support @builder with inheritance, have to add a workaround to fix it and from bugs to fixes there's quite a bit of delay
Hi,
@jdubois Relating to your comment:
On a third project, we achieved 30% performance increase by recoding the equals/hashcode from Lombok
How did you messure this increase?
Was it runtime or compilation time increase?
Can you describe data types on which you tested this 30% increase?
Best,
Lukasz
Runtime performance, on beans that have many fields this is quite logical. Anyway you shouldn't auto generate those.
I am suspecting it may be doing it through runtime reflection to do the hascode, tostring and equals which would be slow at one point. Their current documentation says otherwise https://projectlombok.org/features/EqualsAndHashCode however, it does do "deep verification" so if you only required shallow verification (i.e. just check the top level elements) then it will be very slow.
We used lombok for a big project fine knowing its limitations. When using it manually it can be applied differently. For some classes there need only in @Getter and @Setter annotations, for others it can be @Data or @Builder and so on. For most of classes @Slf4j can be used safely for example. I see enabling it in automatic way can lead to sophisticated configuration change in generators. But if people use it, then it should be some way to support it for manually added annotations.
Please don't comment on an old issue. If you think this issue still applies, please create a new ticket with proper details.
If you have a question please use Stack Overflow, and tag the question with jhipster. This helps the project to keep the issue tracker clean. Also, Stack Overflow will give your question a larger audience:
- This will increase your chances to get an answer
- Answers will be of higher quality, as there is a voting system
- This will also help other users who might have the same issue, as questions are tagged and easily searchable
Finally, you can also use our chat room on gitter.