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
