[BUG] boolean @Getter conflicts with explicit getter

[broodjetom]

Describe the bug
I found some code that had a private boolean field:

private boolean property;

It had an explicit getter method:

public boolean getProperty() {
    return property;
}

I wanted to replace this getter with a Lombok @Getter, which would result in a isProperty() method, but leaving the getProperty() as a @Deprecated method.

During compiling the following message is logged:

Not generating isProperty(): A method with that name already exists (getProperty)

Funny thing is that if I would rename the getter to something else it would work, for example whateverProperty(). There seems to be some conflict between the "get" and "is" prefix for getters for boolean fields.

Expected behavior

The error message is not correct: there is not a method with that name. The functionality should be changed so this is just allowed, or the error message should be more clear. My preference: I would like to be able to keep (as @Deprecated) an explicit getter method on a boolean field and have the @Getter generated.

Version info (please complete the following information):

• Lombok version 1.18.30
• Platform openjdk
  11.0.17 2022-10-18
  OpenJDK Runtime Environment Temurin-11.0.17+8 (build 11.0.17+8)
  OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (build 11.0.17+8, mixed mode)

[Rawi01]

I agree that we could optimize the error message a little bit but at least it already prints the name of the conflicting method. To fix your problem you can add @Tolerate to your explicit getter.

[rzwitserloot]

It's intended behaviour. Leaving the issue open solely for improving the error message we produce here.

[rzwitserloot]

Multiline errors? I'd have to check what that looks like in eclipse and intellij. item 2 also feels superfluous.

I'm not sure if that was your intention, @nell-shark but I think it's fine to special case it here. There are 2 options:

1. The method that already exists has a name that matches exactly. In other words, you have getFoo() and lombok would generate getFoo(). In which case the error message can remain simple: Not generating %s(): A method with that name already exists, as it does now.
2. The method that already exists has a name that doesn't match. It's got different casing, or it's got an is/get discrepancy going on. (Going by memory, lombok does ignore same-letters-different-casing situations, primarily due to beanspec weirdness in regards to fields that start with 2 or more capital letters. int xAxis turns into getXAxis() according to some beanspecs and getxAxis() in others): Then a longer error message that is more specific about 'the other name'. Specifically in this case, I guess we can mention @Tolerate on a second line if multiline errors look acceptable on all relevant platforms.