Use lombok for biolerplate code [FEATURE]

[mhewedy]

Overview of the issue

https://projectlombok.org/ provides simple annotation that help write clean code, like the @Data annotation that I can see it might be very useful on Entity classes.

JHipster Version(s)

1.8.5

[jdubois]

This has already been discussed so many times....

[mhewedy]

So, Why not to be an option - not a have to?

[cbornet]

Because of Policy 2

[mhewedy]

Ok. Thanks.

[jdubois]

And because that's going to fail, add tons of bugs to the project, and in the end we will need to maintain this.
I've already been through this, my experience with Lombok on several projects has always been: one guy who introduces this because he saw it at a conference, and who won 30 minutes by not using is IDE, and then lots of people having bugs, who call me for help, and I spend days removing it.
For example, it is known that Lombok doesn't play well with MapStruct, that we use.
Besides, we are just speaking of using Visual Studio Code, we cannot rely on something that need an IDE plugin. That's just going to be annoying to a lot of people.

[mhewedy]

@jdubois,
Of course one can take the generated project and can easily apply lombok annotation instead of making the whole people affect. (even if it is an option, which might affect the generator codebase)

But still, I hope if lombok (especially @Data) is there, but this is your call at the end.

[cbornet]

@MuhammadHewedy just why would you want to generate code at compile time when the generator you use can do it at generation time:

• you don't have to write the code yourself anyway so you don't even gain time !
• you get the troubles @jdubois speaks about
• you shouldn't have to go look at the entity classes very often so the fact that it has more loc is not important

[mhewedy]

I believe code generations is not good, so IMHO, minimising the (not-so-good) generated code is a good idea.

[deepu105]

What do you mean by code generation is not good? Doesn't lombok also
generate code during compilation? So what is the difference other than your
entities looking a bit cleaner

Thanks & regards,
Deepu

On 15 Sep 2016 04:56, "Muhammad Hewedy" [email protected] wrote:

I believe code generations is not good, so IMHO, minimising the
(not-so-good) generated code is a good idea.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4141 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF3jRDLp8gDE74hwy2UtBq3r1ZPl3ks5qqIKPgaJpZM4J899a
.

[mhewedy]

@deepu105

Generating binary files (bytecode in case of Java) during compilation is not code generation, because the output is not source code. This is why we don't consider javac as a code generator.

Even spring-framework generates byte code which we don't consider code generation.

Code generation is the process of generating source code that could be used/edited by the developer.

Why (getters/setters/toString/equals/hascode/and others) is better when using lombok instead of using the IDE features to do so, IMHO for many reason, most obvious one is the code is much clean (besides this is not a code generation).

https://www.wikiwand.com/en/Automatic_programming#/Source_code_generation

[cbornet]

@MuhammadHewedy even if the code generated is imported by modifying the bytecode, it's still some kind of code generation. You just don't see the intermediate source code.
I understand that you like to have clean entities with few lines of code but that's really a too small benefit for the risk.

[jdubois]

Why are we still talking about this?

Le 15 sept. 2016 11:31 AM, "Muhammad Hewedy" [email protected] a
écrit :

@deepu105 https://github.com/deepu105

Generating binary files (bytecode in case of Java) during compilation
is not code generation, because the output is not source code. This is why
we don't consider javac as a code generator.

Even spring-framework generates byte code which we don't consider code
generation.

Code generation is the process of generating source code that could be
used/edited by the developer.

Why (getters/setters/toString/equals/hascode/and others) is better when
using lombok instead of using the IDE features to do so, IMHO for many
reason, most obvious one is the code is much clean (besides this is not a
code generation).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#4141 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATVo5QzeGzb0FM63R6efhXhQxbL5oMKks5qqRBmgaJpZM4J899a
.

[PierreBesson]

@MuhammadHewedy have a look at the 10 other closed issues relating to Lombok if this is relevant to your interest.
Also please refrain from pursuing the argument for too long after the issue has been closed,. Thank you.

[mhewedy]

Thanks and sorry for this long argument as this is not the right place for.

[sleclercq]

Hi all,

Sorry to beat a dead horse and maybe upset Julien, and I'm not going to open a new ticket for this for obvious reasons considering the JHipster's team views on it. I just wanted to mention that MapStruct and Lombok now play well with each other.

Granted Lombok was horrible before 2012 (I've had some nightmares with it), since then it was always possible with delomboking at the appropriate time during build, and now not a line of black magic is even needed. Contrary to the popular opinion here I've had dozens of spring boot applications in production with lombok (including big monoliths and some microservices) with Lombok, Mapstruct, QueryDSL, etc. and use it heavily as well as all my coworkers with great success.

So while I respect the team's position if you guys don't want to support it directly, I think it shows a limitation of the scaffolding possibilities of JHipster. Does the module / marketplace system allows to change this behavior ? If so, well, I better start working 😄 If not, maybe it's time to open a broader discussion about how 3rd party developers could add modules to JHipster to change its scaffolding behavior and create even more options without involving the core team ? This would comply with the Policy 2 (a.k.a. the anti Lombok policy).

Given the popularity of JHipster and the current avalanche of conferences / talks / podcasts about it and its touted openness and flexibility, I hope that some thought is at least given to this.

Thanks.

[ruddell]

@sleclercq That's the purpose of the module system, so other developers can add features and options without it being in the core code. Please read the other Lombok issue (#664) where we discussed writing a module for this. You are welcome to write a module and this is one of the scenarios that is perfect for it.

I'm locking this topic to contributors so the conversation moves to just one issue.

[deepu105]

@sleclercq if you are writing a module and have issues please let us know and we will be happy to help

[jdubois]

• I have one more thing against Lombok: each time I use Spring Data, which uses Lombok, I have a hard time debugging it and reading the code. I hate it so much, because the programmer didn't bother to click on "generate getters and setters" and put that annotation instead, I lose so much time. Anyway...
• We really can't have this by default, as you need an IDE plugin for it, and it doesn't exist on some IDEs (and is not always stable). That's totally against our philosophy of having a generated application that works out of the box without doing anything.
• It's perfectly fine to discuss this again, technologies change with time, as well as people's opinions, so I have no issue talking about this (well, let's not do this every day, but every few months...)
• I would really like to have Kotlin support in JHipster, and it's kind of the same issue (see, I'm changing my mind here!!). Then, the issue is that we can't support everything in our entity sub-generator. It's already very complex, and we can't have all technologies there. We need to do the maintenance, and it's already a huge task for us (and remember this is mostly done in the evening and week-ends). So the module system should be the best solution, for both Kotlin and Lombok. I'm not totally sure it will work perfectly (I don't do many modules myself!), but if you have any issue with doing a module, like a missing API, just open up a ticket for it.