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 has private access #1704

Closed
nlwillia opened this Issue May 29, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@nlwillia

nlwillia commented May 29, 2018

I have two @Data beans in a parent/child relationship. The parent relies on @Data to generate the required constructor. The child declares its own constructor and calls super. When I compile, I get an error in the Child. Error:(6, 1) java: Base() has private access in com.example.Base

This is new in 1.16.22.

// Base.java
@Data
public class Base {
	private final String baseProperty;
}
// Child.java
@Data
@EqualsAndHashCode(callSuper = true)
public class Child extends Base {

	private final String childProperty;

	public Child(String baseProperty, String childProperty) {
		super(baseProperty);
		this.childProperty = childProperty;
	}
}
// build.gradle
plugins {
	id 'java'
}

sourceCompatibility = 10
targetCompatibility = 10

repositories {
	jcenter()
}

dependencies {
	annotationProcessor 'org.projectlombok:lombok:1.16.22'
	implementation 'org.projectlombok:lombok:1.16.22'
}

I can work around it if I declare a no-arg constructor in the base class manually and add @RequiredArgsConstructor, but this is ugly because I have to come up with defaults for the final fields.

@eximius313

This comment has been minimized.

eximius313 commented May 29, 2018

This could be related to the first feature in changelog: https://projectlombok.org/changelog

@cptwunderlich

This comment has been minimized.

cptwunderlich commented May 29, 2018

Related to Issue #1703

@nlwillia

This comment has been minimized.

nlwillia commented May 29, 2018

Adding lombok.noArgsConstructor.extraPrivate = false to lombok.config at the root of the project does avoid the issue. This seems like something that should be opt-in though and maybe needs some tuning for better decisions in an inheritance scenario. These classes are not serializable (though that may not matter for the frameworks this was introduced for).

@andrebrait

This comment has been minimized.

andrebrait commented Jun 3, 2018

If can also put a @NoArgsConstructor before the @Data like this:

@NoArgsConstructor
@Data
public class Foo {
}

@rspilker rspilker closed this in fb5a553 Jun 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment