Lombok: It can not work when @NoArgsConstructor and @Builder and@Data added

[yanjinbin]

just like this pic
I found it will not work for applying constructor method something wrong
hints: @Data has public constructor without args ,however , i need create a private no args constructor to make the function of not instantiate sense ,
So, what should I do ?

[Maaartinus]

Adding also @AllArgsConstructor should do.

[huehnerlady]

does that mean this is a bug? should the builder annotation work together with the NoArgsConstructor annotation?

[Maaartinus]

@huehnerlady I guess, so. @Builder sort of includes a "weak @AllArgsConstructor", which gets switched off by any explicit @XArgsConstructor annotation. As the @Builder can't work without the constructor, this should probably be strengthened:

It should always generate the needed constructor, unless a "colliding" constructor already exists (defined explicitly or using a Lombok annotation).

Here, "colliding" should mean that defining another one would make the compilation fail, but this isn't always possible, so "same number of arguments" gets used (as elsewhere in Lombok, too).

WDYT?

[janrieke]

What is the exact error message you get? Is it a runtime error when you serialize, or a compile-time error?
If you use lombok 1.18.2, please try the latest edge release 1.18.3, because it includes some fixes for @SuperBuilder that are not in 1.18.2.

[zenglian]

@janrieke I switched to snakeyaml and there is no issue any more.

[janrieke]

Great to hear.
But please do not delete your posts if someone directly replied to them, because it makes the discussion very hard to follow later on.

[wx8900]

@yanjinbin I add two annotations: @NoArgsConstructor and @AllArgsConstructor, it works. Good luck!

[ahmedhamdyse]

Thanks, it works for me

[bvn13]

What is the exact error message you get? Is it a runtime error when you serialize, or a compile-time error?

I have an error

Error:(10, 1) java: constructor MdmAttribute in class com.bvn13.moex.mdm.buybackretriever.model.MdmAttribute cannot be applied to given types;
  required: no arguments
  found: java.lang.String,java.lang.String
  reason: actual and formal argument lists differ in length

My code is:

@Builder
@Getter
@Setter
@NoArgsConstructor
@JacksonXmlRootElement(localName = "Attribute")
public class MdmAttribute {

    @JacksonXmlProperty(localName = "CodeAttr")
    private String codeAttr;

    @JacksonXmlProperty(localName = "ValueAttr")
    private String valueAttr;

    @Override
    public String toString() {
        return String.format("Attribute{CodeAttr=%s, ValueAttr=%s}", codeAttr, valueAttr);
    }

}

Also tried with @Data instead of @Getter + @Setter - causes the same error.

[mostafaghanyomar]

Hi @bvn13 I think it's the same as this issue too:
Duplicate of https://github.com/rzwitserloot/lombok/issues/816#
it all boils down to using @Builder in general whilst Using the default Constructor new Foo(), it doesn't matter if you added @NoArgsConstructor or not
The fastest and simplest solution is as @Maaartinus said, adding @AllArgsConstructor to your @NoArgsConstructor

[lgoldstein]

While adding @AllArgsConstructor is a workaround there are major software design issues with having such a constructor - especially for classes with many fields, and even more so when there are fields with same type. Imagine reading a code like this:

Foo foo = new Foo(1, 2, true, false, 3, false, 5, true);

How can you tell what all these numbers and flags mean - what fields do they reference. This is where the builder pattern makes sense:

Foo foo = Foo.builder()
    .minCount(1)
    .maxCount(2)
    .allowGaps(true)
    .allowOutOfRange(false)
   ...etc...

Why can't the @Builder annotation simply assume/enforce a @NoArgsConstructor and then simply invoke the relevant setter ?. If backward compatibility is an issue then let's invent a new annotation @SetterBasedBuilder that implies the above behavior.

[janrieke]

Because there may be no setters. And final fields cannot be set even directly.

The only way is to switch over to a constructor that uses the builder instance as its only parameter. However, this is backwards-incompatible and very likely to break existing code, so that's not an option.
If you want that approach, use @SuperBuilder.

Otherwise, use a private constructor. It's still ugly, but at least not very visible.

[antillean]

In this comment on #1912, @rzwitserloot said that this behaviour is intended.

[zhangyuhangk]

Adding also @AllArgsConstructor should do.

Saved my ass. Thanks.

[cooligc]

This seems to be a critical defect . We cannot use @Builder on a JPA entity

[janrieke]

Please explain why adding @AllArgsConstructor does not solve this issue for you.

[cooligc]

Please explain why adding @AllArgsConstructor does not solve this issue for you.

It does solve the issue after putting @AllArgsConstructor. Thanks for the help.
My point here was, Why to have unnecessary constructor in place which is not getting used.
Just for the shake of using @Builder we need to have @NoArgsConstructor and @AllArgsConstructor. @janrieke what is your thought on this ?

[Maaartinus]

@cooligc You're not stating it exactly. A lone @Builder works, as it creates its constructor itself. It's the presence of the @NoArgsConstructor which prevents it as an explicit @XConstructor annotation suppresses the implicit @AllArgsConstructor.

I'm not sure, if this should be changed. Obviously, the @Builder can't do anything with the @NoArgsConstructor, but the rules are already complicated.

Actually, I don't understand how @Builder and @NoArgsConstructor can make any sense together. With the latter I obviously want a fully mutable object so why do I need the former?

[theangi]

Well, it may be useful in order to create cleaner tests with @Builder. I ended up with an object with @Builder, @NoArgsContructor and @AllArgsContructor

[sgupta304]

It should be noted that this is still a bug, even if it resolves the issue

[phisad]

It should be noted that this is still a bug, even if it resolves the issue

It's not a bug, but a design choice to honor explicitly set annotations which totally makes sense.

[isen-ng]

I just ran into this and had to search the internet to find this issue.
I understand that this is a design choice, but by now, you should be able to tell that people, intuitively, are going to use@Builder @NoArgsConstructor as their first choice and run into this exception.

Then they have to search the internet, read this thread and finally figure out that "by design" this exception is expected.

Isn't this a hassle? Shouldn't software design be more intuitive?

I understand that this may be a design choice, but it seems that the UX is lacking. Perhaps, the error message could be more descriptive since we know this is a common pitfall. Eg, "You may have specified @Builder and @NoArgsContructor together. Try adding a @AllArksConstructor to make this go away".

[ivangreene]

Or better yet, just let the combination of @Data and @Builder be used as a signal that the constructor variants required by each need to be generated

[Art-B]

It should be noted that this is still a bug, even if it resolves the issue

It's not a bug, but a design choice to honor explicitly set annotations which totally makes sense.

Sorry but how is it not a bug when you need to specify both? I mean why do I need to add @AllArgsConstructor to get @NoArgsConstructor to behave? This at least violates the principle of least surprise

[phisad]

It should be noted that this is still a bug, even if it resolves the issue

It's not a bug, but a design choice to honor explicitly set annotations which totally makes sense.

Sorry but how is it not a bug when you need to specify both? I mean why do I need to add @AllArgsConstructor to get @NoArgsConstructor to behave? This at least violates the principle of least surprise

If I recall correctly, you need @AllArgsConstructor to make @Builder to behave, which makes sense, because you explicitly forced a @NoArgsConstructor which overwrites the builders defaults.

Well, as mentioned above, it could be forced that builder creates the all-args constructor regardless of other annotations which seems a good idea.