[jira] [Closed] (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

["Eric Milles (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-10821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Milles closed GROOVY-10821.
--------------------------------
    Resolution: Information Provided

> 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
>            Priority: Major
>
> 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)