You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2022/05/11 01:05:37 UTC
[DISCUSS] Groovy 5 planning
Hi folks,
We still have a few things on our TODO list to improve Groovy 4, like
performance and some regressions, but we also need to start planning
for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
begin, so feel free to comment, but I don't expect many of us will
have time to act on big items straight away. As always, Apache
"do-ocracy" wins the day for starting progress on such items!
For now, I mostly just want to tackle one aspect right now - the
minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
4 but I think we need to bump to at least JDK11 for Groovy 5.
We have a VMPlugin mechanism which allows us to make use of features
in newer JDKs without bumping up the minimum version and we'd still
continue with that approach. However, there are many API changes in
the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
of those changes through the VMPlugin mechanism would blow out the
associated interface(s) substantially and limit certain choices.
Bumping to JDK11 provides a nice compromise on keeping just the more
critical functionality in the VMPlugin hierarchy and allows us to
start removing our usage of deprecated JDK APIs and moving to their
replacements in other places in the codebase. (As a concrete example,
groovy-console uses the deprecated modelToView method from TextUI
which is replaced with modelToView2D in JDK9+. It is a lot cleaner
just moving to the new APIs than pushing that through the VMPlugin
mechanism).
Some other projects have moving straight to JDK17 on their roadmaps. I
am not proposing we do that as yet but I'm interested in others'
views. Groovy has typically tried to keep the minimum version as low
as possible only jumping to when functionality dictated it as
necessary. Offering users features similar to what Java provides but
on earlier JDK versions has been one of Groovy's selling points for
many users. Further Groovy 5 roadmap discussions may make the case
stronger for JDK minimum greater than 11, but for now I was proposing
we take the first small step and cross other bridges when we get to
them.
A related but orthogonal discussion we need to have is when to phase
out our (optional) use of the SecurityManager-related APIs (related to
JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
suggest Groovy 6 is the version for removal. Having said that, we
could consider parts of the codebase like groovysh as candidates for
removing the security manager in Groovy 5 - though the Java team
haven't proposed their replacement for our System.exit interception as
of yet. So, for Groovy 5 timeframes, we might need additional ways to
opt out of calls into the security related APIs for those using the
latest JDKs. Again, I'm interested in others' thoughts here.
Cheers, Paul.
Re: [DISCUSS] Groovy 5 planning
Posted by Paul King <pa...@asert.com.au>.
Comments inline. Basically, I agree other things might push us to JDK17
but I don't see them yet and I am just trying to see if we have consensus
to go to at least JDK11. If so, we can start the work and if we later go to 17
it will be a smaller incremental jump from 11.
On Wed, May 11, 2022 at 5:18 PM Jochen Theodorou <bl...@gmx.org> wrote:
>
> On 11.05.22 03:05, Paul King wrote:
> > Hi folks,
> >
> > We still have a few things on our TODO list to improve Groovy 4, like
> > performance and some regressions, but we also need to start planning
> > for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> > begin, so feel free to comment, but I don't expect many of us will
> > have time to act on big items straight away. As always, Apache
> > "do-ocracy" wins the day for starting progress on such items!
> >
> > For now, I mostly just want to tackle one aspect right now - the
> > minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> > 4 but I think we need to bump to at least JDK11 for Groovy 5.
>
> In my experience JDK11 or higher is very widespread by now.
>
> > We have a VMPlugin mechanism which allows us to make use of features
> > in newer JDKs without bumping up the minimum version and we'd still
> > continue with that approach. However, there are many API changes in
> > the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> > of those changes through the VMPlugin mechanism would blow out the
> > associated interface(s) substantially and limit certain choices.
> > Bumping to JDK11 provides a nice compromise on keeping just the more
> > critical functionality in the VMPlugin hierarchy and allows us to
> > start removing our usage of deprecated JDK APIs and moving to their
> > replacements in other places in the codebase. (As a concrete example,
> > groovy-console uses the deprecated modelToView method from TextUI
> > which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> > just moving to the new APIs than pushing that through the VMPlugin
> > mechanism).
>
> I would not want the VMPlugin mechanism depend on graphics classes. If
> something like that, I would probably do something comparable just for
> that module as internal API.
>
> > Some other projects have moving straight to JDK17 on their roadmaps.
>
> afaik many more things have been deprecated in the time from 11 to 17
> and partially replaced with new APIs, so a JDK17 build will probably be
> required, but I would fix the decision on details. Like for example the
> upcoming SecurityManager removal.. it is deprecated in 17 already I thnk.
Re "on details": In master, we currently have @SuppressWarnings("deprecation")
on all the affected code up to JDK17. There aren't that many cases,
and basically
only 3 kinds:
* the already mentioned modelToView2D
* isAccessible() calls to become canAccess()
* getPackage() to become getDefinedPackage()
There are a few other cases but they aren't really JDK version related.
All of these would be fixed by going to JDK9 or above.
Long story short - for now JDK11 is all we need.
> > I
> > am not proposing we do that as yet but I'm interested in others'
> > views. Groovy has typically tried to keep the minimum version as low
> > as possible only jumping to when functionality dictated it as
> > necessary. Offering users features similar to what Java provides but
> > on earlier JDK versions has been one of Groovy's selling points for
> > many users.
>
> Groovy was able to run on pretty old version of Java in a time where
> Java had a quite stable API, new major versions took years and
> deprecation barely happened. That is all over now. And that means for
> Groovy that that stand is very difficult. With limited resources it is
> better to go with the new version, than to spend a lot of time in
> finding ways to conform to old and new versions at the same time. The
> last big change in the past was the support for Java5. And the changes
> required in codebase to fully switch to 5 then took many years.
>
> > Further Groovy 5 roadmap discussions may make the case
> > stronger for JDK minimum greater than 11, but for now I was proposing
> > we take the first small step and cross other bridges when we get to
> > them.
>
> I must say I do not follow the features of new Java versions all that
> much anymore. It is just too much to get used to a new version every
> half year in detail, when that is not what you are doing as part of your
> job. Java 17 being an LTS version is then of course different. But Java
> 17 does not have any features I "need" in my projects. The foreign
> memory access API could be interesting (and dangerous). But does it
> require a Groovy adaption? Sealed classes are interesting language wise.
> For me they are overengineering in class design. the whole purpose of
> those is actually supporting pattern matching with a closed set of
> classes, to be able to ensure your matching covers all cases. Afaik we
> do not even do that for enums (and I never used that even in Java)
Currently, you could use a custom type checker extension to handle
enums or sealed hierarchies but we don't currently provide that out of the box.
> > A related but orthogonal discussion we need to have is when to phase
> > out our (optional) use of the SecurityManager-related APIs (related to
> > JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> > suggest Groovy 6 is the version for removal. Having said that, we
> > could consider parts of the codebase like groovysh as candidates for
> > removing the security manager in Groovy 5 - though the Java team
> > haven't proposed their replacement for our System.exit interception as
> > of yet.
>
> What really annoys me about
> https://bugs.openjdk.java.net/browse/JDK-8199704 and comparable ones is
> that the first deprecate an API, without having replacements for the
> obvious problems. It means that the version, that provides the new API
> will be most likely a version that has the SecurityManager removed,
> stealing from you the ability of a transition.
>
> The question is where a SecurityManager is still relevant. Applets are
> gone. That leaves server side scripting.. for example Jenkins. What do
> they think about the removal of the security manager I wonder?
Yes, it would be really good if better visibility was available on JDK-8199704
alternatives. We have about 80 occurrences of code affected by JEP-411,
all marked with @SuppressWarnings("removal"). About 1/3 is test code.
Apart from one case related to groovysh (and with a fix coming in 4.0.3)
so far up to JDK18 and some early versions of JDK19 it is safe for most
Groovy users to ignore. It degrades gracefully.
For users wanting security features (protecting access to files, allowing
only certain system properties to be read, disabling reading cut-n-paste
buffer, etc.) they need a switch on JDK18 of -Djava.security.manager=allow.
Long story short - JDK17 doesn't offer any benefit for security, i.e.
for now the jump to JDK11 minimum is all we need.
> bye Jochen
Re: [DISCUSS] Groovy 5 planning
Posted by Jochen Theodorou <bl...@gmx.org>.
On 11.05.22 03:05, Paul King wrote:
> Hi folks,
>
> We still have a few things on our TODO list to improve Groovy 4, like
> performance and some regressions, but we also need to start planning
> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> begin, so feel free to comment, but I don't expect many of us will
> have time to act on big items straight away. As always, Apache
> "do-ocracy" wins the day for starting progress on such items!
>
> For now, I mostly just want to tackle one aspect right now - the
> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> 4 but I think we need to bump to at least JDK11 for Groovy 5.
In my experience JDK11 or higher is very widespread by now.
> We have a VMPlugin mechanism which allows us to make use of features
> in newer JDKs without bumping up the minimum version and we'd still
> continue with that approach. However, there are many API changes in
> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> of those changes through the VMPlugin mechanism would blow out the
> associated interface(s) substantially and limit certain choices.
> Bumping to JDK11 provides a nice compromise on keeping just the more
> critical functionality in the VMPlugin hierarchy and allows us to
> start removing our usage of deprecated JDK APIs and moving to their
> replacements in other places in the codebase. (As a concrete example,
> groovy-console uses the deprecated modelToView method from TextUI
> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> just moving to the new APIs than pushing that through the VMPlugin
> mechanism).
I would not want the VMPlugin mechanism depend on graphics classes. If
something like that, I would probably do something comparable just for
that module as internal API.
> Some other projects have moving straight to JDK17 on their roadmaps.
afaik many more things have been deprecated in the time from 11 to 17
and partially replaced with new APIs, so a JDK17 build will probably be
required, but I would fix the decision on details. Like for example the
upcoming SecurityManager removal.. it is deprecated in 17 already I thnk.
> I
> am not proposing we do that as yet but I'm interested in others'
> views. Groovy has typically tried to keep the minimum version as low
> as possible only jumping to when functionality dictated it as
> necessary. Offering users features similar to what Java provides but
> on earlier JDK versions has been one of Groovy's selling points for
> many users.
Groovy was able to run on pretty old version of Java in a time where
Java had a quite stable API, new major versions took years and
deprecation barely happened. That is all over now. And that means for
Groovy that that stand is very difficult. With limited resources it is
better to go with the new version, than to spend a lot of time in
finding ways to conform to old and new versions at the same time. The
last big change in the past was the support for Java5. And the changes
required in codebase to fully switch to 5 then took many years.
> Further Groovy 5 roadmap discussions may make the case
> stronger for JDK minimum greater than 11, but for now I was proposing
> we take the first small step and cross other bridges when we get to
> them.
I must say I do not follow the features of new Java versions all that
much anymore. It is just too much to get used to a new version every
half year in detail, when that is not what you are doing as part of your
job. Java 17 being an LTS version is then of course different. But Java
17 does not have any features I "need" in my projects. The foreign
memory access API could be interesting (and dangerous). But does it
require a Groovy adaption? Sealed classes are interesting language wise.
For me they are overengineering in class design. the whole purpose of
those is actually supporting pattern matching with a closed set of
classes, to be able to ensure your matching covers all cases. Afaik we
do not even do that for enums (and I never used that even in Java)
> A related but orthogonal discussion we need to have is when to phase
> out our (optional) use of the SecurityManager-related APIs (related to
> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> suggest Groovy 6 is the version for removal. Having said that, we
> could consider parts of the codebase like groovysh as candidates for
> removing the security manager in Groovy 5 - though the Java team
> haven't proposed their replacement for our System.exit interception as
> of yet.
What really annoys me about
https://bugs.openjdk.java.net/browse/JDK-8199704 and comparable ones is
that the first deprecate an API, without having replacements for the
obvious problems. It means that the version, that provides the new API
will be most likely a version that has the SecurityManager removed,
stealing from you the ability of a transition.
The question is where a SecurityManager is still relevant. Applets are
gone. That leaves server side scripting.. for example Jenkins. What do
they think about the removal of the security manager I wonder?
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
RE: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>.
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: [DISCUSS] Groovy 5 planning
Posted by Daniel Sun <su...@apache.org>.
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: [DISCUSS] Groovy 5 planning
Posted by Jochen Theodorou <bl...@gmx.org>.
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: [DISCUSS] Groovy 5 planning
Posted by MG <mg...@arscreat.com>.
That is exactly what I was thinking: Do not support Java 8 in Groovy 5,
but backport (as has been done in the past) some stuff to
Java8-supporting Groovy 4 G-)
Cheers,
mg
On 27/06/2022 00:04, James Bond wrote:
> perhaps an earlier version of Groovy will continue to suffice for them
> until they can move to a more recent JVM.
>
Re: [DISCUSS] Groovy 5 planning
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.06.22 00:04, James Bond wrote:
> I think Daniel has a point here. I too have been in FinServ (on the
> periphery) for many years, and I know how slow to adopt new standards
> organizations like banks can be.
>
> That being said, I would like to suggest two relatively obvious things
> to consider:
>
> 1) what's the time frame for Groovy 5 to be released?
let's say it would be another two years... if support is till 2030 it is
likely to find lots of Java8 till 2030 and beyond. Especially in those
big organizations. There will be a considerable time frame with Java8
support running and Groovy 5 out. Heck, with that time frame we might
speak about Groovy 7+ even.
> 2) what is the rate of the Java 8 dependent organizations switching to a
> newer version, where will they be at the time Groovy 5 is released, and
> (I hate to say it), how large of a percentage of the total Groovy using
> developer population are they?
That would be indeed interesting to know, but those numbers do not exist.
> I've watched how the Groovy developer
> community is very good about continuing to release new versions of older
> version of Groovy, to be sure to include necessary fixes, etc. It's
> possible that since these "laggards" (not by choice, necessarily) cannot
> move beyond Java 8, perhaps an earlier version of Groovy will continue
> to suffice for them until they can move to a more recent JVM.
The problem is that it means double the effort for every back port fix,
where the code base diverged a lot. On the other hand we have to
consider what type of fix would even be back ported? Security related
stuff and most likely problems in the compiler (minus new features)?
Those could possibly be done together without too much effort.
> I, for one, would not like to see Groovy held back by catering to the
> LCD, especially if that LCD is a very small percentage of the total
> developer population. I think Groovy needs to remain up to date and be
> able to fully leverage all the more recent Java runtime and JVM
> improvements to remain relevant.
Up-to-date means for me means many things here.
(1) have Groovy running on newer JVMs. That requires in the best case
only an update of the asm library
(2) transfer new language features to Groovy. They make the new Java
versions interesting for most people and while I see a need for this it
is not urgent
(3) handle conflicting API. Sometimes a new method is added to a Java
class, that already exists under the same name in Groovy, but has a
different logic. Usually we then remove the Groovy method in favor of
the Java one. But that is a breaking change and would not be backported.
Nether the less it will increase the code base divergence.
(4) handle deprecated/removed API. This part is imho a big deal. Before
Java9 we simply did not have this problem, making it much more easy to
have a Groovy 1.x, Groovy 2.x and Groovy 3.x. In Groovy 4 we removed the
old callsite caching with us expecting Java8 to go out of business soon
and the module system to become a *must*. We still have to deal with the
fallout from that one. The SecurityManager is another big project. Is
Groovy 4 still Groovy 4, if we simply remove it? If we limit the Groovy4
support to be really Groovy on Java8, then it means to keep the
SecurityManager infrastructure in Groovy4 and remove it in Groovy5+
Also assume it is 2030, we have Groovy 7 and Groovy 4 in parallel...
what is the next version? Assuming they do not extend the extended
support for other versions it would be Java21 for 1 year.
> My 2c, as a long time Groovy fan, but first time poster.
you are welcome to write more often
bye Jochen
Re: [DISCUSS] Groovy 5 planning
Posted by James Bond <sb...@gmail.com>.
I think Daniel has a point here. I too have been in FinServ (on the
periphery) for many years, and I know how slow to adopt new standards
organizations like banks can be.
That being said, I would like to suggest two relatively obvious things
to consider:
1) what's the time frame for Groovy 5 to be released?
2) what is the rate of the Java 8 dependent organizations switching to a
newer version, where will they be at the time Groovy 5 is released, and
(I hate to say it), how large of a percentage of the total Groovy using
developer population are they? I've watched how the Groovy developer
community is very good about continuing to release new versions of older
version of Groovy, to be sure to include necessary fixes, etc. It's
possible that since these "laggards" (not by choice, necessarily) cannot
move beyond Java 8, perhaps an earlier version of Groovy will continue
to suffice for them until they can move to a more recent JVM.
I, for one, would not like to see Groovy held back by catering to the
LCD, especially if that LCD is a very small percentage of the total
developer population. I think Groovy needs to remain up to date and be
able to fully leverage all the more recent Java runtime and JVM
improvements to remain relevant.
My 2c, as a long time Groovy fan, but first time poster.
Thank you for reading this,
Steve
On 6/26/22 10:39 AM, 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.
>
> Cheers,
> Daniel Sun
>
> On 2022/05/11 01:05:37 Paul King wrote:
>> Hi folks,
>>
>> We still have a few things on our TODO list to improve Groovy 4, like
>> performance and some regressions, but we also need to start planning
>> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
>> begin, so feel free to comment, but I don't expect many of us will
>> have time to act on big items straight away. As always, Apache
>> "do-ocracy" wins the day for starting progress on such items!
>>
>> For now, I mostly just want to tackle one aspect right now - the
>> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
>> 4 but I think we need to bump to at least JDK11 for Groovy 5.
>>
>> We have a VMPlugin mechanism which allows us to make use of features
>> in newer JDKs without bumping up the minimum version and we'd still
>> continue with that approach. However, there are many API changes in
>> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
>> of those changes through the VMPlugin mechanism would blow out the
>> associated interface(s) substantially and limit certain choices.
>> Bumping to JDK11 provides a nice compromise on keeping just the more
>> critical functionality in the VMPlugin hierarchy and allows us to
>> start removing our usage of deprecated JDK APIs and moving to their
>> replacements in other places in the codebase. (As a concrete example,
>> groovy-console uses the deprecated modelToView method from TextUI
>> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
>> just moving to the new APIs than pushing that through the VMPlugin
>> mechanism).
>>
>> Some other projects have moving straight to JDK17 on their roadmaps. I
>> am not proposing we do that as yet but I'm interested in others'
>> views. Groovy has typically tried to keep the minimum version as low
>> as possible only jumping to when functionality dictated it as
>> necessary. Offering users features similar to what Java provides but
>> on earlier JDK versions has been one of Groovy's selling points for
>> many users. Further Groovy 5 roadmap discussions may make the case
>> stronger for JDK minimum greater than 11, but for now I was proposing
>> we take the first small step and cross other bridges when we get to
>> them.
>>
>> A related but orthogonal discussion we need to have is when to phase
>> out our (optional) use of the SecurityManager-related APIs (related to
>> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
>> suggest Groovy 6 is the version for removal. Having said that, we
>> could consider parts of the codebase like groovysh as candidates for
>> removing the security manager in Groovy 5 - though the Java team
>> haven't proposed their replacement for our System.exit interception as
>> of yet. So, for Groovy 5 timeframes, we might need additional ways to
>> opt out of calls into the security related APIs for those using the
>> latest JDKs. Again, I'm interested in others' thoughts here.
>>
>> Cheers, Paul.
>>
Re: [DISCUSS] Groovy 5 planning
Posted by Daniel Sun <su...@apache.org>.
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.
Cheers,
Daniel Sun
On 2022/05/11 01:05:37 Paul King wrote:
> Hi folks,
>
> We still have a few things on our TODO list to improve Groovy 4, like
> performance and some regressions, but we also need to start planning
> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> begin, so feel free to comment, but I don't expect many of us will
> have time to act on big items straight away. As always, Apache
> "do-ocracy" wins the day for starting progress on such items!
>
> For now, I mostly just want to tackle one aspect right now - the
> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> 4 but I think we need to bump to at least JDK11 for Groovy 5.
>
> We have a VMPlugin mechanism which allows us to make use of features
> in newer JDKs without bumping up the minimum version and we'd still
> continue with that approach. However, there are many API changes in
> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> of those changes through the VMPlugin mechanism would blow out the
> associated interface(s) substantially and limit certain choices.
> Bumping to JDK11 provides a nice compromise on keeping just the more
> critical functionality in the VMPlugin hierarchy and allows us to
> start removing our usage of deprecated JDK APIs and moving to their
> replacements in other places in the codebase. (As a concrete example,
> groovy-console uses the deprecated modelToView method from TextUI
> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> just moving to the new APIs than pushing that through the VMPlugin
> mechanism).
>
> Some other projects have moving straight to JDK17 on their roadmaps. I
> am not proposing we do that as yet but I'm interested in others'
> views. Groovy has typically tried to keep the minimum version as low
> as possible only jumping to when functionality dictated it as
> necessary. Offering users features similar to what Java provides but
> on earlier JDK versions has been one of Groovy's selling points for
> many users. Further Groovy 5 roadmap discussions may make the case
> stronger for JDK minimum greater than 11, but for now I was proposing
> we take the first small step and cross other bridges when we get to
> them.
>
> A related but orthogonal discussion we need to have is when to phase
> out our (optional) use of the SecurityManager-related APIs (related to
> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> suggest Groovy 6 is the version for removal. Having said that, we
> could consider parts of the codebase like groovysh as candidates for
> removing the security manager in Groovy 5 - though the Java team
> haven't proposed their replacement for our System.exit interception as
> of yet. So, for Groovy 5 timeframes, we might need additional ways to
> opt out of calls into the security related APIs for those using the
> latest JDKs. Again, I'm interested in others' thoughts here.
>
> Cheers, Paul.
>
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by Remi Forax <fo...@univ-mlv.fr>.
> From: "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>
> To: "dev" <de...@groovy.apache.org>
> Sent: Wednesday, May 11, 2022 3:29:54 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
> Is there a compelling reason to drop support for Java 8? I don't see it holding
> us back quite like Java 7 support in Groovy 2.5 means no use of lambdas,
> optional, functional interfaces, etc.
from the POV of a parser,
you have access to methods like Integer.parseInt(CharSequence) which avoid to create a String token before transforming it to an int.
from the POV of a bytecode generator, you have two major features,
- nestmates which tell the VM that it's fine to access private field/methods from other classes given they come from the same script,
so less need to use reflection at runtime
- constantdynamic which allow to share constant values in between callsites of the same classes. Unlike invokedynamic which requires c2 to kick in to get performance, c1 is enough.
A simple example is def a = 42; here 42 need to be converted to an Object (an Integer), it can be done each time or with a constant dynamic, once the first time you need it.
from the POV of the runtime,
- you are in a post module world and you can ditch the invocation part of the reflection API (you still need it for the discovery part)
- you get access to Lookup.accessClass, findClass and defineClass. The last one makes the creation of named class dynamically far easier (it makes the GroovyClassLoader far less useful), the other two avoid to have you own checks in the runtime duplicating the one of the VM.
- you can reduce your dependency to sun.misc.Unsafe using VarHandles instead, for lock-free algorithms of your runtime.
- you have ClassLoader.getDefinedPackages()
- you have the StackWalker API, easier to get the caller method info of things like that (you even get the bytecode index of each stack frame)
- you have more method handles, zero(), tryFinally() and empty()
- you have access to Runtime.version() so detecting the version of Java becomes easy.
regards,
Rémi
> From: Paul King <pa...@asert.com.au>
> Sent: Wednesday, May 11, 2022 7:58 AM
> To: Groovy_Developers <de...@groovy.apache.org>
> Subject: [EXT] Re: [DISCUSS] Groovy 5 planning
> External Email: Use caution with links and attachments.
> I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11
> support was phased out. It might be the case then that Groovy 4 and Groovy 6
> are our "sort of LTS" versions at that point.
> On Wed, May 11, 2022 at 2:22 PM J. David Beutel < [ mailto:list@getsu.com |
> list@getsu.com ] > wrote:
>> One thing to consider is the EOL schedule, of course. Oracle advertises[1]
>> "extended support" for its Java customers for:
>> JDK version
>> until
>> 8
>> 2030*
>> 11
>> 2026
>> 17
>> 2029
>> * "The Extended Suppo rt uplift fee will be waived for the period March 2022 -
>> December 2030 for Java SE 8. During this period, you will receive Extended
>> Support as described in the Oracle Technical Support Level sections of the
>> Technical Support Policies."
>> On the other hand, Oracle's "premier support" for JDK11 ends in 2023.
>> Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11 until
>> 2024.
>> Cheers,
>> 11011011
>> [1] [
>> https://urldefense.com/v3/__https:/www.oracle.com/java/technologies/java-se-support-roadmap.html__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDkDFNyn8g$
>> |
>> https://www.oracle.com/java/technologies/java-se-support-roadmap.html ]
>> [2] [
>> https://urldefense.com/v3/__https:/access.redhat.com/articles/1299013__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDmI5II-Tg$
>> |
>> https://access.redhat.com/articles/1299013 ]
>> On 2022-05-10 15:05 , Paul King wrote:
>>> Hi folks,
>>> We still have a few things on our TODO list to improve Groovy 4, like
>>> performance and some regressions, but we also need to start planning
>>> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
>>> begin, so feel free to comment, but I don't expect many of us will
>>> have time to act on big items straight away. As always, Apache
>>> "do-ocracy" wins the day for starting progress on such items!
>>> For now, I mostly just want to tackle one aspect right now - the
>>> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
>>> 4 but I think we need to bump to at least JDK11 for Groovy 5.
>>> We have a VMPlugin mechanism which allows us to make use of features
>>> in newer JDKs without bumping up the minimum version and we'd still
>>> continue with that approach. However, there are many API changes in
>>> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
>>> of those changes through the VMPlugin mechanism would blow out the
>>> associated interface(s) substantially and limit certain choices.
>>> Bumping to JDK11 provides a nice compromise on keeping just the more
>>> critical functionality in the VMPlugin hierarchy and allows us to
>>> start removing our usage of deprecated JDK APIs and moving to their
>>> replacements in other places in the codebase. (As a concrete example,
>>> groovy-console uses the deprecated modelToView method from TextUI
>>> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
>>> just moving to the new APIs than pushing that through the VMPlugin
>>> mechanism).
>>> Some other projects have moving straight to JDK17 on their roadmaps. I
>>> am not proposing we do that as yet but I'm interested in others'
>>> views. Groovy has typically tried to keep the minimum version as low
>>> as possible only jumping to when functionality dictated it as
>>> necessary. Offering users features similar to what Java provides but
>>> on earlier JDK versions has been one of Groovy's selling points for
>>> many users. Further Groovy 5 roadmap discussions may make the case
>>> stronger for JDK minimum greater than 11, but for now I was proposing
>>> we take the first small step and cross other bridges when we get to
>>> them.
>>> A related but orthogonal discussion we need to have is when to phase
>>> out our (optional) use of the SecurityManager-related APIs (related to
>>> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
>>> suggest Groovy 6 is the version for removal. Having said that, we
>>> could consider parts of the codebase like groovysh as candidates for
>>> removing the security manager in Groovy 5 - though the Java team
>>> haven't proposed their replacement for our System.exit interception as
>>> of yet. So, for Groovy 5 timeframes, we might need additional ways to
>>> opt out of calls into the security related APIs for those using the
>>> latest JDKs. Again, I'm interested in others' thoughts here.
>>> Cheers, Paul.
RE: [EXT] Re: [DISCUSS] Groovy 5 planning
Posted by "Milles, Eric (TR Technology)" <er...@thomsonreuters.com>.
Is there a compelling reason to drop support for Java 8? I don't see it holding us back quite like Java 7 support in Groovy 2.5 means no use of lambdas, optional, functional interfaces, etc.
From: Paul King <pa...@asert.com.au>
Sent: Wednesday, May 11, 2022 7:58 AM
To: Groovy_Developers <de...@groovy.apache.org>
Subject: [EXT] Re: [DISCUSS] Groovy 5 planning
External Email: Use caution with links and attachments.
I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11 support was phased out. It might be the case then that Groovy 4 and Groovy 6 are our "sort of LTS" versions at that point.
On Wed, May 11, 2022 at 2:22 PM J. David Beutel <li...@getsu.com>> wrote:
One thing to consider is the EOL schedule, of course. Oracle advertises[1] "extended support" for its Java customers for:
JDK version
until
8
2030*
11
2026
17
2029
* "The Extended Support uplift fee will be waived for the period March 2022 - December 2030 for Java SE 8. During this period, you will receive Extended Support as described in the Oracle Technical Support Level sections of the Technical Support Policies."
On the other hand, Oracle's "premier support" for JDK11 ends in 2023.
Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11 until 2024.
Cheers,
11011011
[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html<https://urldefense.com/v3/__https:/www.oracle.com/java/technologies/java-se-support-roadmap.html__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDkDFNyn8g$>
[2] https://access.redhat.com/articles/1299013<https://urldefense.com/v3/__https:/access.redhat.com/articles/1299013__;!!GFN0sa3rsbfR8OLyAw!bb6_MeGN-73wJ61WVbbOSp6bvWENnVdRT1txFW18y8GpXo8Mmlb7VBHyHu1-bcyDz4njUuGa9XADfDmI5II-Tg$>
On 2022-05-10 15:05 , Paul King wrote:
Hi folks,
We still have a few things on our TODO list to improve Groovy 4, like
performance and some regressions, but we also need to start planning
for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
begin, so feel free to comment, but I don't expect many of us will
have time to act on big items straight away. As always, Apache
"do-ocracy" wins the day for starting progress on such items!
For now, I mostly just want to tackle one aspect right now - the
minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
4 but I think we need to bump to at least JDK11 for Groovy 5.
We have a VMPlugin mechanism which allows us to make use of features
in newer JDKs without bumping up the minimum version and we'd still
continue with that approach. However, there are many API changes in
the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
of those changes through the VMPlugin mechanism would blow out the
associated interface(s) substantially and limit certain choices.
Bumping to JDK11 provides a nice compromise on keeping just the more
critical functionality in the VMPlugin hierarchy and allows us to
start removing our usage of deprecated JDK APIs and moving to their
replacements in other places in the codebase. (As a concrete example,
groovy-console uses the deprecated modelToView method from TextUI
which is replaced with modelToView2D in JDK9+. It is a lot cleaner
just moving to the new APIs than pushing that through the VMPlugin
mechanism).
Some other projects have moving straight to JDK17 on their roadmaps. I
am not proposing we do that as yet but I'm interested in others'
views. Groovy has typically tried to keep the minimum version as low
as possible only jumping to when functionality dictated it as
necessary. Offering users features similar to what Java provides but
on earlier JDK versions has been one of Groovy's selling points for
many users. Further Groovy 5 roadmap discussions may make the case
stronger for JDK minimum greater than 11, but for now I was proposing
we take the first small step and cross other bridges when we get to
them.
A related but orthogonal discussion we need to have is when to phase
out our (optional) use of the SecurityManager-related APIs (related to
JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
suggest Groovy 6 is the version for removal. Having said that, we
could consider parts of the codebase like groovysh as candidates for
removing the security manager in Groovy 5 - though the Java team
haven't proposed their replacement for our System.exit interception as
of yet. So, for Groovy 5 timeframes, we might need additional ways to
opt out of calls into the security related APIs for those using the
latest JDKs. Again, I'm interested in others' thoughts here.
Cheers, Paul.
Re: [DISCUSS] Groovy 5 planning
Posted by Paul King <pa...@asert.com.au>.
I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11
support was phased out. It might be the case then that Groovy 4 and Groovy
6 are our "sort of LTS" versions at that point.
On Wed, May 11, 2022 at 2:22 PM J. David Beutel <li...@getsu.com> wrote:
> One thing to consider is the EOL schedule, of course. Oracle
> advertises[1] "extended support" for its Java customers for:
>
> JDK version
> until
> 8
> 2030*
> 11
> 2026
> 17
> 2029
>
> * "The Extended Support uplift fee will be waived for the period March
> 2022 - December 2030 for Java SE 8. During this period, you will receive
> Extended Support as described in the Oracle Technical Support Level
> sections of the Technical Support Policies."
>
> On the other hand, Oracle's "premier support" for JDK11 ends in 2023.
>
> Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11
> until 2024.
>
> Cheers,
> 11011011
>
> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> [2] https://access.redhat.com/articles/1299013
>
> On 2022-05-10 15:05 , Paul King wrote:
>
> Hi folks,
>
> We still have a few things on our TODO list to improve Groovy 4, like
> performance and some regressions, but we also need to start planning
> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> begin, so feel free to comment, but I don't expect many of us will
> have time to act on big items straight away. As always, Apache
> "do-ocracy" wins the day for starting progress on such items!
>
> For now, I mostly just want to tackle one aspect right now - the
> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> 4 but I think we need to bump to at least JDK11 for Groovy 5.
>
> We have a VMPlugin mechanism which allows us to make use of features
> in newer JDKs without bumping up the minimum version and we'd still
> continue with that approach. However, there are many API changes in
> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> of those changes through the VMPlugin mechanism would blow out the
> associated interface(s) substantially and limit certain choices.
> Bumping to JDK11 provides a nice compromise on keeping just the more
> critical functionality in the VMPlugin hierarchy and allows us to
> start removing our usage of deprecated JDK APIs and moving to their
> replacements in other places in the codebase. (As a concrete example,
> groovy-console uses the deprecated modelToView method from TextUI
> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> just moving to the new APIs than pushing that through the VMPlugin
> mechanism).
>
> Some other projects have moving straight to JDK17 on their roadmaps. I
> am not proposing we do that as yet but I'm interested in others'
> views. Groovy has typically tried to keep the minimum version as low
> as possible only jumping to when functionality dictated it as
> necessary. Offering users features similar to what Java provides but
> on earlier JDK versions has been one of Groovy's selling points for
> many users. Further Groovy 5 roadmap discussions may make the case
> stronger for JDK minimum greater than 11, but for now I was proposing
> we take the first small step and cross other bridges when we get to
> them.
>
> A related but orthogonal discussion we need to have is when to phase
> out our (optional) use of the SecurityManager-related APIs (related to
> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> suggest Groovy 6 is the version for removal. Having said that, we
> could consider parts of the codebase like groovysh as candidates for
> removing the security manager in Groovy 5 - though the Java team
> haven't proposed their replacement for our System.exit interception as
> of yet. So, for Groovy 5 timeframes, we might need additional ways to
> opt out of calls into the security related APIs for those using the
> latest JDKs. Again, I'm interested in others' thoughts here.
>
> Cheers, Paul.
>
>
>
>
Re: [DISCUSS] Groovy 5 planning
Posted by "J. David Beutel" <li...@getsu.com>.
One thing to consider is the EOL schedule, of course. Oracle
advertises[1] "extended support" for its Java customers for:
JDK version
until
8
2030*
11
2026
17
2029
* "The Extended Support uplift fee will be waived for the period March
2022 - December 2030 for Java SE 8. During this period, you will receive
Extended Support as described in the Oracle Technical Support Level
sections of the Technical Support Policies."
On the other hand, Oracle's "premier support" for JDK11 ends in 2023.
Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11
until 2024.
Cheers,
11011011
[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
[2] https://access.redhat.com/articles/1299013
On 2022-05-10 15:05 , Paul King wrote:
> Hi folks,
>
> We still have a few things on our TODO list to improve Groovy 4, like
> performance and some regressions, but we also need to start planning
> for Groovy 5. I am happy for broad ranging discussions on Groovy 5 to
> begin, so feel free to comment, but I don't expect many of us will
> have time to act on big items straight away. As always, Apache
> "do-ocracy" wins the day for starting progress on such items!
>
> For now, I mostly just want to tackle one aspect right now - the
> minimum JDK version for our runtime. We kept that at JDK 8 for Groovy
> 4 but I think we need to bump to at least JDK11 for Groovy 5.
>
> We have a VMPlugin mechanism which allows us to make use of features
> in newer JDKs without bumping up the minimum version and we'd still
> continue with that approach. However, there are many API changes in
> the JDK for JDK9+ changes related to JPMS and elsewhere. Pushing all
> of those changes through the VMPlugin mechanism would blow out the
> associated interface(s) substantially and limit certain choices.
> Bumping to JDK11 provides a nice compromise on keeping just the more
> critical functionality in the VMPlugin hierarchy and allows us to
> start removing our usage of deprecated JDK APIs and moving to their
> replacements in other places in the codebase. (As a concrete example,
> groovy-console uses the deprecated modelToView method from TextUI
> which is replaced with modelToView2D in JDK9+. It is a lot cleaner
> just moving to the new APIs than pushing that through the VMPlugin
> mechanism).
>
> Some other projects have moving straight to JDK17 on their roadmaps. I
> am not proposing we do that as yet but I'm interested in others'
> views. Groovy has typically tried to keep the minimum version as low
> as possible only jumping to when functionality dictated it as
> necessary. Offering users features similar to what Java provides but
> on earlier JDK versions has been one of Groovy's selling points for
> many users. Further Groovy 5 roadmap discussions may make the case
> stronger for JDK minimum greater than 11, but for now I was proposing
> we take the first small step and cross other bridges when we get to
> them.
>
> A related but orthogonal discussion we need to have is when to phase
> out our (optional) use of the SecurityManager-related APIs (related to
> JEP-411). If we keep the minimum for Groovy 5 as JDK11, then I would
> suggest Groovy 6 is the version for removal. Having said that, we
> could consider parts of the codebase like groovysh as candidates for
> removing the security manager in Groovy 5 - though the Java team
> haven't proposed their replacement for our System.exit interception as
> of yet. So, for Groovy 5 timeframes, we might need additional ways to
> opt out of calls into the security related APIs for those using the
> latest JDKs. Again, I'm interested in others' thoughts here.
>
> Cheers, Paul.
>