[BUG] @Data does not generate all the Getters and Setters

[Y0Username]

Describe the bug
@Data does not generate all the expected Getters and Setters when there are two class members with and without is prefix. Example: manager v/s isManager. Furthermore Getter and Setter generated also depend on the order of these class members.

Source:

@Data
public class Employee {
    private String manager;
    private boolean isManager;
}

Generated:

public String getManager() {
    return this.manager;
}

public void setManager(String manager) {
    this.manager = manager;
}

^ This does not generate Getter and Setter for isManager

Source:

@Data
public class Employee {
    private boolean isManager;
    private String manager;
}

Generated:

public boolean isManager() {
    return this.isManager;
}

public String getManager() {
    return this.manager;
}

public void setManager(boolean isManager) {
    this.isManager = isManager;
}

^ This does not generate the Setter for manager: setManager(String manager)

To Reproduce
Compile the source:

@Data
public class Employee {
    private String manager;
    private boolean isManager;
}

And check the generated source. Also, change the order of the member variables, compile and check the generated source.

Expected behavior
There should be Getters and Setters for all the members of the class:

public boolean isManager() {
    return this.isManager;
}

public String getManager() {
    return this.manager;
}

public void setManager(boolean isManager) {
    this.isManager = isManager;
}

public void setManager(String manager) {
    this.manager = manager;
}

Version info (please complete the following information):

• Lombok version: 1.18.30
• Platform: javac 11.0.22

Additional context
This also messes up how jackson handles serialization.
The workaround is to add lombok.getter.noIsPrefix = true to lombok.config.

[rspilker]

Yeah, the problem is the beanspec. Both manager and isManager are supposed to have their setter called setManager. Possibly this isn't even a problem because the parameter would be different.

Did you try @Tolerate?