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/05/11 13:29:54 UTC
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: 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: [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.