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 <dev@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) <eric.mil...@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 <dev@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)
