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)" <er...@thomsonreuters.com> on 2021/11/06 18:24:14 UTC
RE: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
+1 binding
Can the new methods in ClassNode be named getRecordComponents and setRecordComponents? The "Node" seems unnecessary and verbose. ClassNode doesn't offer getFieldNodes() or getFieldNode(String) and so on.
The elevation of target bytecode does have implications for tooling. If you use "record" in your source, the compiler expects to be able to load the classes in its VM, which means you must run your compiler/editor on Java 16 or whatever just to work with records (or sealed classes I would imagine).
Is it really necessary to supply CompilerConfiguration.isPostJDK* methods beyond what was already there (5-9)? This pattern does not scale and you can use StringGroovyMethods.isAtLeast(version, CompilerConfiguration.JDK*) directly for any of the constants.
-----Original Message-----
From: Paul King <pa...@asert.com.au>
Sent: Friday, November 5, 2021 7:30 PM
To: Groovy_Developers <de...@groovy.apache.org>
Subject: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
External Email: Use caution with links and attachments.
Dear development community,
I am happy to start the VOTE thread for a Groovy 4.0.0-beta-2 release!
This release includes 104 bug fixes/improvements as outlined in the changelog:
https://urldefense.com/v3/__https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12350212__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bcQIlyLc$
Tag: https://urldefense.com/v3/__https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs*tags*GROOVY_4_0_0_BETA_2__;Ly8!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b9hhpRPA$
Tag commit id: 666b0084241f10293aa57175664ab4ca9764e3cb
The artifacts to be voted on are located as follows (r50820).
Source release:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/groovy/4.0.0-beta-2/sources__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bOhK1cMc$
Convenience binaries:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/groovy/4.0.0-beta-2/distribution__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b7PlLl1k$
Release artifacts are signed with a key from the following file:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/release/groovy/KEYS__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bJi3wTyY$
Please vote on releasing this package as Apache Groovy 4.0.0-beta-2.
Reminder on ASF release approval requirements for PMC members:
https://urldefense.com/v3/__http://www.apache.org/legal/release-policy.html*release-approval__;Iw!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bABbUGzE$
Hints on validating checksums/signatures (but replace md5sum with sha256sum):
https://urldefense.com/v3/__https://www.apache.org/info/verification.html__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bu9U6qgs$
The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast.
[ ] +1 Release Apache Groovy 4.0.0-beta-2 [ ] 0 I don't have a strong opinion about this, but I assume it's ok [ ] -1 Do not release Apache Groovy 4.0.0-beta-2 because...
Here is my vote:
+1 (binding)
RE: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
Posted by "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>.
I did some additional investigation into why compiler/editor was having trouble with records. I started with a project that targets Java 16. However, it wasn't until I added a record type that evaluateExpression (from StaticTypeCheckingSupport) kicked in as part of processing the RecordType annotation. It is the evaluation that copies the project compiler config and then loads a small class within the compiler's JVM. So my tooling runs Java 11 and my project targets Java 16, so there was an issue.
I have a couple enhancements to StaticTypeCheckingSupport#evaluateExpression that should reduce the scope of this issue. They should be coming in a Pull Request very soon.
-----Original Message-----
From: Paul King <pa...@asert.com.au>
Sent: Tuesday, November 9, 2021 5:37 AM
To: Groovy_Developers <de...@groovy.apache.org>
Subject: Re: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
Eric, thanks for the +1 vote, further responses inline below.
Cheers, Paul.
On Sun, Nov 7, 2021 at 4:24 AM Milles, Eric (TR Technology) <er...@thomsonreuters.com> wrote:
>
> +1 binding
>
> Can the new methods in ClassNode be named getRecordComponents and setRecordComponents? The "Node" seems unnecessary and verbose. ClassNode doesn't offer getFieldNodes() or getFieldNode(String) and so on.
Sorted for next release with a deprecated alias for the existing name.
> The elevation of target bytecode does have implications for tooling. If you use "record" in your source, the compiler expects to be able to load the classes in its VM, which means you must run your compiler/editor on Java 16 or whatever just to work with records (or sealed classes I would imagine).
There is a tooling implication but it may not be obvious, so I'll expand here. I'll expand here for records/JDK16 but the same is true for sealed classes/JDK17.
You can use the "record" keyword or "@RecordType" annotation in your source. If target bytecode is 16 or above you will get a native record regardless of which syntax you use and similarly you will get an emulated record for JDK8-15 regardless of which syntax.
If you don't like this auto adapting behavior there is a mode annotation attribute on @RecordOptions. You can state you always want an emulated record-like class across all JDK versions. You can alternatively state explicitly that you want a native record in which case you will get a compile error if your JDK/target bytecode version isn't appropriate.
So, there are some assumptions there for tooling.
On top of the above, Groovy 4 now defaults to setting the target bytecode to the version of the JDK being used - to match Java behavior
(GROOVY-10286) though you can obviously still be explicit if you want.
Historically, unless an explicit value was given, Groovy tried to set the value as low as possible and auto bump it up to the minimum value required for some functionality (5 for annotations, 7 for indy, 8 for lambdas etc.) regardless of the JDK version being used.
We haven't done exhaustive testing yet with different IDEs and build systems to see if there are unknown assumptions with respect to the bytecode version that might be impacted by this change.
I'd be keen for any help with doing more testing and documenting behavior for the common IDEs and build tools so we can adjust documentation and release notes as appropriate.
> Is it really necessary to supply CompilerConfiguration.isPostJDK* methods beyond what was already there (5-9)? This pattern does not scale and you can use StringGroovyMethods.isAtLeast(version, CompilerConfiguration.JDK*) directly for any of the constants.
I guess they aren't strictly necessary but here is my thinking. The general trend seems to be to avoid using methods which take a string and use stronger typed options. For similar functionality, Gradle seems to go to JDK12 (e.g. isJava12Compatible()) though now seems to prefer an enum solution. Adding two methods a year or adding two additional enum constants a year seems to have similar scaling characteristics. We'll still keep the scripting flavored methods as well but folks using that might have extra doco to look up to get the format of the string correct etc. or to find out where to find the appropriately defined constants.
>
> -----Original Message-----
> From: Paul King <pa...@asert.com.au>
> Sent: Friday, November 5, 2021 7:30 PM
> To: Groovy_Developers <de...@groovy.apache.org>
> Subject: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
>
> External Email: Use caution with links and attachments.
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 4.0.0-beta-2 release!
>
> This release includes 104 bug fixes/improvements as outlined in the changelog:
> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/Rele
> aseNote.jspa?projectId=12318123&version=12350212__;!!GFN0sa3rsbfR8OLyA
> w!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bcQIl
> yLc$
>
> Tag:
> https://urldefense.com/v3/__https://gitbox.apache.org/repos/asf?p=groo
> vy.git;a=tag;h=refs*tags*GROOVY_4_0_0_BETA_2__;Ly8!!GFN0sa3rsbfR8OLyAw
> !Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b9hhpR
> PA$ Tag commit id: 666b0084241f10293aa57175664ab4ca9764e3cb
>
> The artifacts to be voted on are located as follows (r50820).
> Source release:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/gro
> ovy/4.0.0-beta-2/sources__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB
> 222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bOhK1cMc$
> Convenience binaries:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/gro
> ovy/4.0.0-beta-2/distribution__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5Ss
> DhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b7PlLl1k$
>
> Release artifacts are signed with a key from the following file:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/release
> /groovy/KEYS__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQH
> rUiKlFAo53xK29EywASr6vGB7sMg5bJi3wTyY$
>
> Please vote on releasing this package as Apache Groovy 4.0.0-beta-2.
>
> Reminder on ASF release approval requirements for PMC members:
> https://urldefense.com/v3/__http://www.apache.org/legal/release-policy
> .html*release-approval__;Iw!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB
> 222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bABbUGzE$
> Hints on validating checksums/signatures (but replace md5sum with sha256sum):
> https://urldefense.com/v3/__https://www.apache.org/info/verification.h
> tml__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo5
> 3xK29EywASr6vGB7sMg5bu9U6qgs$
>
> The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 4.0.0-beta-2 [ ] 0 I don't have a strong opinion about this, but I assume it's ok [ ] -1 Do not release Apache Groovy 4.0.0-beta-2 because...
>
> Here is my vote:
>
> +1 (binding)
Re: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
Posted by Paul King <pa...@asert.com.au>.
Eric, thanks for the +1 vote, further responses inline below.
Cheers, Paul.
On Sun, Nov 7, 2021 at 4:24 AM Milles, Eric (TR Technology)
<er...@thomsonreuters.com> wrote:
>
> +1 binding
>
> Can the new methods in ClassNode be named getRecordComponents and setRecordComponents? The "Node" seems unnecessary and verbose. ClassNode doesn't offer getFieldNodes() or getFieldNode(String) and so on.
Sorted for next release with a deprecated alias for the existing name.
> The elevation of target bytecode does have implications for tooling. If you use "record" in your source, the compiler expects to be able to load the classes in its VM, which means you must run your compiler/editor on Java 16 or whatever just to work with records (or sealed classes I would imagine).
There is a tooling implication but it may not be obvious, so I'll
expand here. I'll expand here for records/JDK16 but the same is true
for sealed classes/JDK17.
You can use the "record" keyword or "@RecordType" annotation in your
source. If target bytecode is 16 or above you will get a native record
regardless of which syntax you use and similarly you will get an
emulated record for JDK8-15 regardless of which syntax.
If you don't like this auto adapting behavior there is a mode
annotation attribute on @RecordOptions. You can state you always want
an emulated record-like class across all JDK versions. You can
alternatively state explicitly that you want a native record in which
case you will get a compile error if your JDK/target bytecode version
isn't appropriate.
So, there are some assumptions there for tooling.
On top of the above, Groovy 4 now defaults to setting the target
bytecode to the version of the JDK being used - to match Java behavior
(GROOVY-10286) though you can obviously still be explicit if you want.
Historically, unless an explicit value was given, Groovy tried to set
the value as low as possible and auto bump it up to the minimum value
required for some functionality (5 for annotations, 7 for indy, 8 for
lambdas etc.) regardless of the JDK version being used.
We haven't done exhaustive testing yet with different IDEs and build
systems to see if there are unknown assumptions with respect to the
bytecode version that might be impacted by this change.
I'd be keen for any help with doing more testing and documenting
behavior for the common IDEs and build tools so we can adjust
documentation and release notes as appropriate.
> Is it really necessary to supply CompilerConfiguration.isPostJDK* methods beyond what was already there (5-9)? This pattern does not scale and you can use StringGroovyMethods.isAtLeast(version, CompilerConfiguration.JDK*) directly for any of the constants.
I guess they aren't strictly necessary but here is my thinking. The
general trend seems to be to avoid using methods which take a string
and use stronger typed options. For similar functionality, Gradle
seems to go to JDK12 (e.g. isJava12Compatible()) though now seems to
prefer an enum solution. Adding two methods a year or adding two
additional enum constants a year seems to have similar scaling
characteristics. We'll still keep the scripting flavored methods as
well but folks using that might have extra doco to look up to get the
format of the string correct etc. or to find out where to find the
appropriately defined constants.
>
> -----Original Message-----
> From: Paul King <pa...@asert.com.au>
> Sent: Friday, November 5, 2021 7:30 PM
> To: Groovy_Developers <de...@groovy.apache.org>
> Subject: [EXT] [VOTE] Release Apache Groovy 4.0.0-beta-2
>
> External Email: Use caution with links and attachments.
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 4.0.0-beta-2 release!
>
> This release includes 104 bug fixes/improvements as outlined in the changelog:
> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12350212__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bcQIlyLc$
>
> Tag: https://urldefense.com/v3/__https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs*tags*GROOVY_4_0_0_BETA_2__;Ly8!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b9hhpRPA$
> Tag commit id: 666b0084241f10293aa57175664ab4ca9764e3cb
>
> The artifacts to be voted on are located as follows (r50820).
> Source release:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/groovy/4.0.0-beta-2/sources__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bOhK1cMc$
> Convenience binaries:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/groovy/4.0.0-beta-2/distribution__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5b7PlLl1k$
>
> Release artifacts are signed with a key from the following file:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/release/groovy/KEYS__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bJi3wTyY$
>
> Please vote on releasing this package as Apache Groovy 4.0.0-beta-2.
>
> Reminder on ASF release approval requirements for PMC members:
> https://urldefense.com/v3/__http://www.apache.org/legal/release-policy.html*release-approval__;Iw!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bABbUGzE$
> Hints on validating checksums/signatures (but replace md5sum with sha256sum):
> https://urldefense.com/v3/__https://www.apache.org/info/verification.html__;!!GFN0sa3rsbfR8OLyAw!Lw3-JMgqD2iRnj5SsDhjOB222W8j20OTQHrUiKlFAo53xK29EywASr6vGB7sMg5bu9U6qgs$
>
> The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 4.0.0-beta-2 [ ] 0 I don't have a strong opinion about this, but I assume it's ok [ ] -1 Do not release Apache Groovy 4.0.0-beta-2 because...
>
> Here is my vote:
>
> +1 (binding)