The domain classes have a lot of getters/setters. Why not use lombok? http://projectlombok.org/
+1
We are not using Lombok because:
@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:
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.
-> 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:
@jdubois thanks for sharing your experiences. I think I'll avoid lombok myself.
Oh, and I just got 2 more:
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:
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.
@senyor
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:
Finally, you can also use our chat room on gitter.
Most helpful comment
@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:
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.