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.
