[jira] [Created] (GROOVY-10821) Potential regression for isser/getter preference in classes with an isser and a not boolean getter for a property of the same name.

["Marcin Erdmann (Jira)" <ji...@apache.org>]

Marcin Erdmann created GROOVY-10821:
---------------------------------------

             Summary: Potential regression for isser/getter preference in classes with an isser and a not boolean getter for a property of the same name.
                 Key: GROOVY-10821
                 URL: https://issues.apache.org/jira/browse/GROOVY-10821
             Project: Groovy
          Issue Type: Bug
    Affects Versions: 4.0.0
            Reporter: Marcin Erdmann


Given the following class:
{code}
class ClassWithConflictingAccessors {
    boolean isConflictingProperty() {
        true
    }

    String getConflictingProperty() {
        "getter"
    }
}
{code}
The following passes on Groovy 3
{code}
class AccessorsRegressionSpec extends Specification {
    def "getter is preferred for accessors when there is an isser and non-boolean getter"() {
        expect:
        new ClassWithConflictingAccessors().conflictingProperty == "getter"
    }
}
{code}
But fails on Groovy 4:
{noformat}
Condition not satisfied:

new ClassWithConflictingAccessors().conflictingProperty == "getter"
|                                   |                   |
|                                   true                false
<Cl...@533b5d47>
{noformat}

I suspect that this is related to https://github.com/apache/groovy/pull/1599 but it is somewhat an edge case because the getter has a non-boolean return type. I understand that this would be considered a bad design to have such accessors in a Groovy class but there are examples of this out there in the wild ([{{JiraAuthenticationContext.getLoggedInUser()}}|https://docs.atlassian.com/software/jira/docs/api/9.3.0/com/atlassian/jira/security/JiraAuthenticationContextImpl.html#getLoggedInUser--] and [{{JiraAuthenticationContext.isLoggedInUser()}}|https://docs.atlassian.com/software/jira/docs/api/9.3.0/com/atlassian/jira/security/JiraAuthenticationContextImpl.html#isLoggedInUser--] as well as [{{Issue.getCreated()}}|https://docs.atlassian.com/software/jira/docs/api/9.3.0/com/atlassian/jira/issue/Issue.html#getCreated--] and [{{Issue.isCreated()}}|https://docs.atlassian.com/software/jira/docs/api/9.3.0/com/atlassian/jira/issue/Issue.html#isCreated--]) which are heavily used by users of the product I'm working on and this would be a massive breaking change for them.

I'm wondering if a PR with reverting this behaviour to what it was pre Groovy 4 only for the situation where the getter is non-boolean would be considered? I understand that this might been working like that not by design but it did and this can potentially be considered a regression.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)