Re: [EXT] Groovy 5 next steps
Jochen Theodorou <[email protected]>
| Newsgroups | gmane.comp.lang.groovy.devel |
|---|---|
| Message-ID | <[email protected]> |
On 29.07.25 15:24, Milles, Eric (TR Technology) via dev wrote:
> I have an open PR for GROOVY-8283 that could benefit from review and
> consideration for inclusion. This item represents a change in priority
> between public access methods and protected fields. And the changes in
> ScriptBytecodeAdapter -- namely checking the receiver class methods for
> override -- could use another set of eyes. I thought about the
> possibility of passing sender class through ThreadLocal or some other
> means since the getProperty API cannot change.
As far as I can tell the change should be correct. I would not use
ThreadLocal though. Java now changes all the time, so maybe my knowledge
is a bit outdated, but it used to be a quite heavy solution with lots of
problems for inlining and other things. If it is
"receiver.getClass().getMethod("getProperty", String.class).isDefault()"
you want to keep as information, then maybe ClassValue could be used
instead.
One point though... does this mean we are currently not using indy to
set properties?
https://github.com/apache/groovy/blob/cceb3c7b944f784db7d05310c4d6d7f2d9528c59/src/main/java/org/codehaus/groovy/vmplugin/v8/Selector.java#L285
was thought for this.
Also there is a big difference... The selector goes by @Internal,
instead of using the default modifier. Not that I find superior to the
other, but it is bad if one code does that and another code does it
different to achieve the same goal.
bye Jochen