Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

szpak opened this issue Jan 15, 2020 · 1 comment


Copy link

@szpak szpak commented Jan 15, 2020

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$ 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?


This comment has been minimized.

Copy link
Member Author

@szpak szpak commented Jan 17, 2020

Created an issue in Groovy: . Paul K. declared to take a look at that in the Groovy 4 development.

@szpak szpak added this to the 2.0 milestone Feb 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.