You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org> on 2025/07/29 13:24:31 UTC
Re: [EXT] Groovy 5 next steps
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.
________________________________
From: Paul King <pa...@asert.com.au>
Sent: Tuesday, July 29, 2025 4:27 AM
To: Groovy_Developers <de...@groovy.apache.org>
Subject: [EXT] Groovy 5 next steps
External Email: Use caution with links and attachments.
Hi folks,
I think Groovy 5 is ready for RC1. The new REPL still needs some refinement but is in good shape. We have some upstream PRs that will fix some of the remaining issues, and some have already been merged. We have workarounds in place for most things in any case.
Let me know if you think there is anything else that needs doing; otherwise, I'll kick off another release in a few days.
Cheers, Paul.
Re: [EXT] Groovy 5 next steps
Posted by Paul King <pa...@asert.com.au>.
I'll take a look.
Paul.
On Tue, Jul 29, 2025 at 11:24 PM Milles, Eric (TR Technology) via dev <
dev@groovy.apache.org> 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.
>
> ------------------------------
> *From:* Paul King <pa...@asert.com.au>
> *Sent:* Tuesday, July 29, 2025 4:27 AM
> *To:* Groovy_Developers <de...@groovy.apache.org>
> *Subject:* [EXT] Groovy 5 next steps
>
> *External Email:* Use caution with links and attachments.
>
> Hi folks,
>
> I think Groovy 5 is ready for RC1. The new REPL still needs some
> refinement but is in good shape. We have some upstream PRs that will fix
> some of the remaining issues, and some have already been merged. We have
> workarounds in place for most things in any case.
>
> Let me know if you think there is anything else that needs doing;
> otherwise, I'll kick off another release in a few days.
>
> Cheers, Paul.
>
>
Re: [EXT] Groovy 5 next steps
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
> does this mean we are currently not using indy to set properties?
I think the path for setting a property falls through past the indy path and into dynamic (aka ScriptBytecodeAdapter). That could be looked at separately. My best guess is because of the possibility of setter overloads, it was not taken up into indy.
________________________________
From: Jochen Theodorou <bl...@gmx.org>
Sent: Tuesday, July 29, 2025 5:25 PM
To: dev@groovy.apache.org <de...@groovy.apache.org>
Subject: Re: [EXT] Groovy 5 next steps
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://urldefense.com/v3/__https://github.com/apache/groovy/blob/cceb3c7b944f784db7d05310c4d6d7f2d9528c59/src/main/java/org/codehaus/groovy/vmplugin/v8/Selector.java*L285__;Iw!!GFN0sa3rsbfR8OLyAw!clt0Gq00Acd2uMNSC3C_caIiNuucCL-622CLRSkx7fHQM2Sg6yGWFn33OBvzkTVvQgzzIizwZrVsndI-x393IQev$
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
Re: [EXT] Groovy 5 next steps
Posted by Jochen Theodorou <bl...@gmx.org>.
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