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 <sun...@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 >
