New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.16.22 - constructor ... already defined in class #1703

Closed
MrPlow442 opened this Issue May 29, 2018 · 7 comments

Comments

Projects
None yet
7 participants
@MrPlow442

MrPlow442 commented May 29, 2018

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

This comment has been minimized.

dreis2211 commented May 29, 2018

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

This comment has been minimized.

Contributor

Maaartinus commented May 29, 2018

@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

This comment has been minimized.

dreis2211 commented May 29, 2018

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

This comment has been minimized.

eximius313 commented May 29, 2018

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

This comment has been minimized.

chriskessel commented May 29, 2018

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

@rspilker

This comment has been minimized.

Collaborator

rspilker commented May 29, 2018

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

@andrebrait

This comment has been minimized.

andrebrait commented Jun 3, 2018

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 {
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment