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