[BUG] Lombok generates only one @Getter and @Setter for a field name

[vadym-l]

I want to emphasize that this issue is not related to "the first letter should be lowercase" like #757 and a pile of others.

Describe the bug
Lombok generates only one Getter/Setter for fields which names are differed by the case.

To Reproduce
When I have a class with fields that have the following names:

    @Getter
    @Setter
    public class Cases {
        String name;
        String naMe;
        String nAME;
    }

Lombok generates only 1 pair of getter and setter

        Cases cases = new Cases();
        cases.setName("");
        cases.getName();

Expected behavior
I expect lombok to generate 3 pairs of getter and setters

        Cases cases = new Cases();
        cases.setName("");
        cases.setNaMe("");
        cases.setNAME("");
        cases.getName();
        cases.getNaMe();
        cases.getNAME();

Version info:

• Lombok version 1.18.8
• javac 1.8.0_201
• Eclipse Lombok v1.18.4 "Envious Ferret" is installed

Additional context
From the documentation - https://projectlombok.org/features/GetterSetter

No method is generated if any method already exists with the same name (case insensitive) and same parameter count.

I don't quite understand this irrational behavior - if these are different fields for Java - Lombok should treat them as separate fields and generate a pair of Getter/Setter for each.

[Maaartinus]

@vadym-l

I don't quite understand this irrational behavior

I guess, the reason is the javabeanscrap insanity: With their rules, there's no one-to-one correspondence between field and getter names. So the names could collide. I don't recall the rules anymore, so I can't give you an example.

Moreover, there are people using their own rules and defining getters manually, when they dislike the name lombok would generate. So when lombok sees getName, it doesn't generate getNaMe.

Sure, it could be smarter when it sees that the first getter was actually generated by lombok itself. But this is more complicated, would break backwards compatibility, would need a precise specification, updating documentation, maintenance.... and seriously, how often do you need it?

[vadym-l]

@Maaartinus , it happens from time to time, and until today I thought that Lombok supports it.

If this change as complex as you describe, then we can leave current behavior as it is, but add more flexibility to the @Getter/@Setter annotations by providing additional attributes, in the same manner as we already have in @Builder (like @Builder(builderMethodName = "")).
For example, by providing an additional attribute "getterName" on the field level, which will allow specifying generated getter method name:

@Getter(getterName = "getNaMe")
String naMe;

which will generate a getter method with name getNaMe()

---

Or by providing an additional attribute "caseSensitive" on the class level:

    @Setter(caseSensitive=true)
    public class Cases {
        String name;
        String naMe;
        String nAME;
    }

which will generate setters for each field considering its naming case:

        Cases cases = new Cases();
        cases.setName("");
        cases.setNaMe("");
        cases.setNAME("");

[Maaartinus]

If this change as complex as you describe

I wouldn't say, it's complex. If it was code generation using reflection or plain annotation processing, I'd vote for finding the best solution. But lombok has to deal with undocumented compiler internals and that adds more than an order of magnitude overhead. And it has many users with many wishes, a few contributors and only two maintainers (I'm not a team member).

by providing an additional attribute "getterName"

... which saves you a single line (or two or zero, depending on your formatting style) in a very rare case of name clash due to different casing. At least, I hope, it's a rare case in your code. 🤣

Or by providing an additional attribute "caseSensitive" on the class level

I guess, lombok.config would be the best place, but many similar proposals were shot down because fulfilling all peoples' wishes would cause an explosion of options (just read through all the @ToString proposals). These options love to interact in unforeseen ways causing unexpected bugs and maintenance costs. There are quite a few options I'd personally love to see in lombok, but I gave up on most of them. Lombok as is saves me maybe half a megabyte of boilerplate (more than Java 8 features do) and much more is hardly achievable (at least not without a medium-sized company backing it).

[rspilker]

Sorry, although I understand that there is a use-case for it, due to the reasons @Maaartinus mentioned, we're not going to add support for multiple fields that have the same case-insensitive name.

It's not common enough to warrant extra time on it.

[rzwitserloot]

Duplicate of #2693