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.
