Lombok: 1.16.22 - constructor ... already defined in class

[MrPlow442]

On 1.16.22 the following class

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Test implements Serializable {

    private String field1;
    private String field2;
    private String field3;

}

refuses to compile with constructor Test() already defined in class. Works as expected in 1.16.20.

[dreis2211]

See the changelog - was hit by this as well:

FEATURE: Private no-args constructor for @Data and @Value to enable deserialization frameworks (like Jackson) to operate out-of-the-box. Use lombok.noArgsConstructor.extraPrivate = false to disable this behavior.

Anyhow, I wonder why this isn't reflected in the release changelog that this breaks with @NoArgsConstructor already being defined. (If it is intended after all). If it is, I wonder why the release version is just a patch increase.

And because the new feature adds a private no-args constructor I wonder how we can change the visibility modifier of the constructor? Shouldn't the one coming from @NoArgsConstructor have precedence over the one from @Data?

[Maaartinus]

@dreis2211

Anyhow, I wonder why this isn't reflected in the release changelog that this breaks with @NoArgsConstructor already being defined. (If it is intended after all).

I'd bet, this is a bug. The only sensible behavior is the explicit annotation taking precedence, i.e., @Value implying a weak @NoArgsConstructor(access=PRIVATE) which gets discarded in case an explicit @NoArgsConstructor is present.

And because the new feature adds a private no-args constructor I wonder how we can change the visibility modifier of the constructor?

IMHO, these two rules make sense:

• explicit wins over implicit
• higher visibility wins (as each annotation adds a feature, combining them means getting the higher visibility as with a public thing you can do everything what you can do with a private one)

In this case both rules agree that there should be a public constructor.

[dreis2211]

I somehow hope this is a bug. This being intended would be "suboptimal" ;)

explicit wins over implicit

We basically agree what we would expect in terms of precedence. 👍

[eximius313]

Sidenote: When I see somebody using @Data I'm always wondering if they're aware, that @Data is using deep equals and if they're aware of consequences...
I think this should be really emphasized in documentation!

[chriskessel]

Came in this morning to the same error. We use AllArgs and NoArgs in most of our POJOs. Things are borked now :(

[rspilker]

Yes, this is a bug. Sorry. Will see how soon we can make a new release.

[andrebrait]

Putting the @NoArgsConstructor before the @Data like will make it prevail over the private no-args constructor generated by @Data

@NoArgsConstructor
@Data
public class Foo {
}