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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.