Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Information Provided
-
4.0.0
-
None
-
None
-
None
Description
Given the following class:
class ClassWithConflictingAccessors { boolean isConflictingProperty() { true } String getConflictingProperty() { "getter" } }
The following passes on Groovy 3
class AccessorsRegressionSpec extends Specification { def "getter is preferred for accessors when there is an isser and non-boolean getter"() { expect: new ClassWithConflictingAccessors().conflictingProperty == "getter" } }
But fails on Groovy 4:
Condition not satisfied: new ClassWithConflictingAccessors().conflictingProperty == "getter" | | | | true false <ClassWithConflictingAccessors@533b5d47>
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() and JiraAuthenticationContext.isLoggedInUser() as well as Issue.getCreated() and Issue.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.
Attachments
Issue Links
- is related to
-
GROOVY-9382 Inconsistent support for [Bb]oolean properties
- Closed
-
GROOVY-10133 Inconsistent method selection for [Bb]oolean properties
- Closed
-
GROOVY-10707 Regression in property access for conflicting isXxx and getXxx accessors
- Closed