Describe the bug
build() method on the builder is not generated, when there is build field in the class, only build(SomeObejct build) is generated.
To Reproduce
Compile this. The FooBarBuilder doesn't have build() method.
@Data
@Builder
public class FooBar {
private final String build;
}
Expected behavior
The builder should have both build() and build(String) methods.
Version info (please complete the following information):
The builder should have both
build()andbuild(String)methods.
IMHO it really should not. Yes, this is a bug, but having two overloads doing something completely different is looking for troubles.
I guess, there'll be more such cases, fields called builder, toBuilder, equals, ...
I'm not sure, if they all are really worth fixing. Just my 2c.
There should be a proper (compile time) error or warning at least.
So there still is a bug to fix.
On Fri, Jan 11, 2019 at 7:07 AM Maaartinus notifications@github.com wrote:
The builder should have both build() and build(String) methods.
IMHO it really should not. Yes, this is a bug, but having two overloads
doing something completely different is looking for troubles.I guess, there'll be more such cases, fields called builder, toBuilder,
equals, ...I'm not sure, if they all are really worth fixing. Just my 2c.
—
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/2011#issuecomment-453388998,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCReDsCoD_InG2aaSZrP0smkpqrILKks5vCCoJgaJpZM4Z5RB4
.
--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven
Right now Java just complains that a method which my IDE plugin says is there actually is not there -- which will be frustrating, so good catch. I think that the plugins should check for this case if it will not be supported.
If you really need to have a variable named build, you can use buildMethodName argument to @Builder annotation to make all these problems go away.
@randakar, would a more all-encompassing fix be to check all method names in output classes against fields for naming collisions during compilation?
It's always better to report problems at the source, rather than having a
strange side effect pop up elsewhere.
On Sat, Jan 12, 2019 at 6:27 PM K. Alex Mills notifications@github.com
wrote:
Right now Java just complains that a method which my IDE plugin says is
there actually is not there -- which will be frustrating, so good catch. I
think that the plugins should check for this case if it will not be
supported.If you really need to have a variable named build, you can use
buildMethodName argument to @builder https://github.com/builder
annotation to make all these problems go away.@randakar https://github.com/randakar, would a more all-encompassing
fix be to check all method names in output classes against fields for
naming collisions during compilation?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/2011#issuecomment-453765598,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRagcs9uiXVlmlqfTlZPxY5yZ217Nks5vChsWgaJpZM4Z5RB4
.
--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven
While I agree with @Maaartinus that having both Foo build() and FooBuilder build(arg) in the same builder doing completely different things makes for _deplorably bad_ API, there is a fine line between the notion of 'lombok should not accidentally generate crappy code' and 'lombok should attempt to eliminate lunacy'.
We hold to the notion that a sufficiently idiotic coder in your team results in bad code. No amount of rules, hooks, linting tools, style guides, and opinionated checker frameworks/software will ever outwit the inventive lunacy of a dedicated moron on a team. With the obvious exception that for some reason even otherwise capable and experienced coders turn into blithering baboons when they are faced with operator overloading so definitely never ever add that to anything. 😛
Having build as a field is sufficiently exotic that I decided to just roll with 'make both methods, let crazy API be damned'.
bugfix available in edge release: https://projectlombok.org/download-edge
Most helpful comment
While I agree with @Maaartinus that having both
Foo build()andFooBuilder build(arg)in the same builder doing completely different things makes for _deplorably bad_ API, there is a fine line between the notion of 'lombok should not accidentally generate crappy code' and 'lombok should attempt to eliminate lunacy'.We hold to the notion that a sufficiently idiotic coder in your team results in bad code. No amount of rules, hooks, linting tools, style guides, and opinionated checker frameworks/software will ever outwit the inventive lunacy of a dedicated moron on a team. With the obvious exception that for some reason even otherwise capable and experienced coders turn into blithering baboons when they are faced with operator overloading so definitely never ever add that to anything. 😛
Having
buildas a field is sufficiently exotic that I decided to just roll with 'make both methods, let crazy API be damned'.