Better way to distinguish go.x and go.getProperty("x") in JavaMockInterceptor

[szpak]

This is an issue to track an ability to better handle calling go.x when the generic Java mock implementation is used for an Groovy object in Groovy 3. Currently a working (but ugly and fragile) workaround (aka "hack") is applied, but we hope to have some better way. Related discussion on the Groovy devel mailing list.

A quotation from the original message:

TL;TR. How would be best to distinguish in Groovy 3 foo.x and foo.getProperty("x") in a call (at the level of an interceptor for a mocking system)?

More detailed version.
Working on the Spock adjustment to Groovy 3, I spotted that Groovy 3 started for a property access go.x (go - some GroovyObject instance with a field "x") to call go.getProperty("x") instead of go.getX() directly (as it took place in Groovy 2). This broke tests for mocking with a property call (getX() is stubbed, but go.x is called) and forced me to detect getProperty("x") calls in a mock interceptor - to analyze deeper and check which method (here getter) is being called and if has been stubbed.

However, in addition, it should be possible to just stub direct go.getProperty("x") calls [1]. To do that, currently, I have to analyze a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper process only the other calls (go.x). It seems to work, but it's quite ugly and fragile. I wonder, how to reliably differentiate those two types of calls?

[szpak]

Created an issue in Groovy: https://issues.apache.org/jira/browse/GROOVY-9369 . Paul K. declared to take a look at that in the Groovy 4 development.

[AndreasTu]

This problem gets worse with Groovy >=4.0.7, because it uses now indy as default, which makes the current used hack in BaseMockInterceptor checking the caller stack useless due to MethodHandle/Indy frames.
#1752 adds a test case for the behavior of >=4.0.7.

[leonard84]

Probably related #1815