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 2022/07/05 14:59:52 UTC
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?
https://issues.apache.org/jira/browse/GROOVY-8299
https://issues.apache.org/jira/browse/GROOVY-9801
https://issues.apache.org/jira/browse/GROOVY-10000
-----Original Message-----
From: Daniel Sun <su...@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
>
RE: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
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)"
> > <er...@thomsonreuters.com>
> > To: "dev" <de...@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 <su...@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
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by Remko Popma <re...@gmail.com>.
That makes sense to me.
On Tue, Aug 9, 2022 at 5:19 AM Guillaume Laforge <gl...@gmail.com> wrote:
> The variant sounds pragmatic to me.
>
> Guillaume
>
>
> Le lun. 8 août 2022, 13:24, Paul King <pa...@asert.com.au> a écrit :
>
>> 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://twitter.com/ApacheGroovy/status/1524255310923595776
>>
>> 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)" <er...@thomsonreuters.com>
>> > > To: "dev" <de...@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://issues.apache.org/jira/browse/GROOVY-8299
>> > > https://issues.apache.org/jira/browse/GROOVY-9801
>> > > https://issues.apache.org/jira/browse/GROOVY-10000
>> >
>> > regards,
>> > Rémi
>> >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Daniel Sun <su...@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
>>
>
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by Guillaume Laforge <gl...@gmail.com>.
The variant sounds pragmatic to me.
Guillaume
Le lun. 8 août 2022, 13:24, Paul King <pa...@asert.com.au> a écrit :
> 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://twitter.com/ApacheGroovy/status/1524255310923595776
>
> 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)" <er...@thomsonreuters.com>
> > > To: "dev" <de...@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://issues.apache.org/jira/browse/GROOVY-8299
> > > https://issues.apache.org/jira/browse/GROOVY-9801
> > > https://issues.apache.org/jira/browse/GROOVY-10000
> >
> > regards,
> > Rémi
> >
> > >
> > >
> > > -----Original Message-----
> > > From: Daniel Sun <su...@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
>
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by Paul King <pa...@asert.com.au>.
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://twitter.com/ApacheGroovy/status/1524255310923595776
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)" <er...@thomsonreuters.com>
> > To: "dev" <de...@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://issues.apache.org/jira/browse/GROOVY-8299
> > https://issues.apache.org/jira/browse/GROOVY-9801
> > https://issues.apache.org/jira/browse/GROOVY-10000
>
> regards,
> Rémi
>
> >
> >
> > -----Original Message-----
> > From: Daniel Sun <su...@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
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by Remi Forax <fo...@univ-mlv.fr>.
----- Original Message -----
> From: "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>
> To: "dev" <de...@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://issues.apache.org/jira/browse/GROOVY-8299
> https://issues.apache.org/jira/browse/GROOVY-9801
> https://issues.apache.org/jira/browse/GROOVY-10000
regards,
Rémi
>
>
> -----Original Message-----
> From: Daniel Sun <su...@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