Just a quick update on this. The current Groovy 5 branch has been moved to JDK11 minimum. We have started to make use of new Java APIs and removed target bytecode support below 11.
Enhancements/fixes currently in Groovy 5: https://issues.apache.org/jira/issues/?jql=project+%3D+GROOVY+AND+fixVersion+%3D+5.0.0-alpha-1 I have some ideas for Groovy 5 enhancements that could benefit from some developer partnering to get them off the ground. 1. Native interfaces - support for static, private and default methods without traits * GROOVY-8299, GROOVY-9801, GROOVY-10000, GROOVY-10060 2. Investigate nest host/mate for access control - GROOVY-10687 * might solve GROOVY-2433, GROOVY-5438, et al. 3. Object (de)structuring enhancements - multi-assign from map, map from local variables, ... * GROOVY-10666, GROOVY-10788, et al. 4. for loop with index/iterator - GROOVY-10683 5. Java 19 preview feature support 6. Java 11 refresh of codebase 7. JUnit 5 refresh of tests Tickets viewable in JIRA: https://issues.apache.org/jira/projects/GROOVY/issues -----Original Message----- From: Paul King <pa...@asert.com.au> Sent: Monday, August 8, 2022 6:24 AM To: dev@groovy.apache.org Subject: Re: [EXT] Re: [DISCUSS] Groovy 5 planning Hi folks, We never really resolved a clear direction for our on-going plans in terms of when to bump our minimum version. There was a poll on twitter back when this discussion started: https://urldefense.com/v3/__https://twitter.com/ApacheGroovy/status/1524255310923595776__;!!GFN0sa3rsbfR8OLyAw!YpMEL4r8G2UL0x57SvFU_nBUTEX4KMZk_TpFPe-be5ZJWDTff7EuudMgAAcdgP_xFhfgk7I2JQsaqgcck28Hpw$ That shows a keen interest in bumping up our minimum version but still a reasonable percentage of folks wanting the status quo. The two obvious choices are: (1) Stick with JDK8 for Groovy 5 and bump for Groovy 6 - the implications being we defer numerous activities that depend on the bump or branch off Groovy 6 earlier rather than later. The downside in having many branches is that it increases our load when cherry-picking/porting fixes across branches. (2) Lock in JDK11 for Groovy 5 (we spoke of potentially jumping to JDK17 if a compelling reason pushed us in that direction - but so far there hasn't been such a reason, so I am suggesting we defer that part of the decision for now). This means that bigger changes for JDK8 might cause 4.1, 4.2, 4.x branches in the future. I'd like to suggest a variant of (2). We start off by bumping master to JDK11. If, before we release Groovy 5, we do end up with a bigger change appearing that might be nice to push back to JDK8, we reserve the right to bump the version in master to 6 and backport such a change onto a newly created 5_0_X branch. Thoughts? Cheers, Paul. On Wed, Jul 6, 2022 at 1:44 AM Remi Forax <fo...@univ-mlv.fr> wrote: > > ----- Original Message ----- > > From: "Milles, Eric (TR Technology)" > > <eric.mil...@thomsonreuters.com> > > To: "dev" <dev@groovy.apache.org> > > Sent: Tuesday, July 5, 2022 4:59:52 PM > > Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning > > > I was interested in native interface default/private/static methods > > (GROOVY-8299, GROOVY-9801, GROOVY-10000) for Groovy 5. There was > > discussion on what was needed for this at one point. Does anyone > > remember if Java 8 was holding us back in this area? > > It does not, Java the language only adds interface private methods in Java 9 > but the VM already supports them since 8. > > As a trivia, the support in the VM was added in 8 to be able to desugar the > body of a lambda as a private method (static or not) when a lambda is used > inside a default method. > > > > > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/GR > > OOVY-8299__;!!GFN0sa3rsbfR8OLyAw!YpMEL4r8G2UL0x57SvFU_nBUTEX4KMZk_Tp > > FPe-be5ZJWDTff7EuudMgAAcdgP_xFhfgk7I2JQsaqgcxSY0GpA$ > > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/GR > > OOVY-9801__;!!GFN0sa3rsbfR8OLyAw!YpMEL4r8G2UL0x57SvFU_nBUTEX4KMZk_Tp > > FPe-be5ZJWDTff7EuudMgAAcdgP_xFhfgk7I2JQsaqgfK99KRXA$ > > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/GR > > OOVY-10000__;!!GFN0sa3rsbfR8OLyAw!YpMEL4r8G2UL0x57SvFU_nBUTEX4KMZk_T > > pFPe-be5ZJWDTff7EuudMgAAcdgP_xFhfgk7I2JQsaqgdcn5rChg$ > > regards, > Rémi > > > > > > > -----Original Message----- > > From: Daniel Sun <sun...@apache.org> > > Sent: Sunday, July 3, 2022 1:21 PM > > To: dev@groovy.apache.org > > Subject: [EXT] Re: [DISCUSS] Groovy 5 planning > > > > External Email: Use caution with links and attachments. > > > > Hi Jochen, > > > > I agree with you. The manpower is always a big problem... > > > > As for the Groovy 5 itself, I wonder what features we should add to the > > release. > > I think following Java's steps is right, but Groovy should have its own > > evolving plan. Also, I think polishing Groovy 4 is important too, e.g. > > fixing > > issues and improving performance. > > > > Cheers, > > Daniel Sun > > On 2022/06/26 21:55:33 Jochen Theodorou wrote: > >> On 26.06.22 19:39, Daniel Sun wrote: > >> > AFAIK, quite a lot of Groovy users are still using Java 8 because > >> > their company have no plan to upgrade systems to run on Java 9+. > >> > It is especially common for bank systems I have been working on > >> > for years, so it's better to continue supporting Java 8 in Groovy 5 > >> > releases. > >> > >> When is it likely for them to change? If we go by the Oracle > >> extended support it would mean to have Java8 in till 2030. > >> > >> if we had the manpower I would suggest making a java8 version of > >> Groovy 5. But I think that is not realistic. It will be difficult > >> to support deprecated/removed API. I mean it is a bit more than in > >> the past where it was about backporting features to older Java > >> versions or enabling language only features on older Java versions. > >> The alternative would then be to not to support that feature anymore... > >> like for example the SecurityManager. But would such a > >> Groovy-Version still be useful in its current usage? > >> > >> > >> bye Jochen
