Hi,
We have been using Lombok in the company i work for and we love it. It makes building POJOs much easier. However, i noticed some improvement that can be done regarding @ Builder Annotation. We have that POJO file, which contains lots of information and has over 255 fields. (The java compiler limits the number of method parameters to 255, so the compilation fails saying method has too many parameters). So for that reason, we had to create a custom builder. Basically rather than using a constructor when we call build, we pass the builder as a parameter of the pojo constructor (private constructor), and since the builder is public static class we can use the fields in the pojo constructor. e.g : value = builder.value
Is this something you possibly have in mind to implement in the future as part of @ Builder to support more than 255 fields in a POJO which is using builder??
More than 255 fields? That's too much for most of us out there. Perhaps you could split that POJO into some smaller ones. And composite them into the original.
yes i agree, its a very specific application though where having that many fields makes it very easy to extend. I would feel like having the capability to use @ Builder even with that many fields would make it nicer. Maybe having a filed on @ Builder annotation like: boolean useConstructor() where default is true?
We don't consider this as a typical scenario. Therefore, we're not going to cater for this. Sorry.
I was just hit by this same problem. The thing is, the "mutant" Pojo is comming from a legacy app I can't control or modify, so I think in that case this is still a valid scenario
Is the purpose of Lombok to cater to all oddball scenarios out there? I
don't think so.
Lombok is there to reduce the amount of boilerplate code you have to write
for commonly occurring problems. This is not a common problem.
In fact, it's not even a good code pattern. Supporting that pattern will
just encourage people to write code like that more often.
No, Lombok should not support it.
Op 28 feb. 2018 00:37 schreef "Jorge Palacio" notifications@github.com:
I was just hit this same problem. The thing is, the "mutant" Pojo is
comming from a legacy app, so I think in that case this is still a valid
scenario—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1509#issuecomment-369066644,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRbna2LKNMmGh97CBWjyAQ4Q0kWuvks5tZJGtgaJpZM4QQ9rk
.
Ok, no problem, sorry If my comment bothered you, I just wanted to show that it is not a rare case to face this issue, and for sure many others will face this same problem in the future as well. Just that.
Actually I'm very happy using Lombok. It has helped me a lot to write clean code very easy.
Thank you!
I'm not bothered.
I'm just saying it's not a common case and even if it were, it shouldn't be.
Op 28 feb. 2018 18:46 schreef "Jorge Palacio" notifications@github.com:
Ok, no problem, sorry If my comment bothered you, I just wanted to show
that it is not a rare case to face this issue, and for sure many others
will face this same problem in the future as well. Just that.Actually I'm very happy using Lombok. It has helped me a lot to write
clean code very easy.Thank you!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1509#issuecomment-369321126,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRWrmirST9fL8pNr2j74iFWZ69iXIks5tZZBBgaJpZM4QQ9rk
.
I met the same problem, the root cause is Lombok created too many parameters constructor in builder which is used in build() method. So please use no-args constructor and setters instead of all-args constructor in build(), @Lombok contributors.
Thank you.
@yuanming-xu As already said, Lombok is there to reduce the amount of boilerplate code you have to write for commonly occurring problems. This isn't the case.
Note that builder is primarily needed for immutable objects, so it can't use setters as there's no such thing there.
When you have setters, then you need no builder, just use @Accessors(fluent=true, chained=true) and feel free to write
new MyMillionFieldsObject().f0(0).f1(1).f2(2)......f999999(999999);
If you can't do this because of some funny framework.... consider annotation processing (or simply reflection) for generating the builder class to a new file.
Most helpful comment
More than 255 fields? That's too much for most of us out there. Perhaps you could split that POJO into some smaller ones. And composite them into the original.