I would certainly hope we had Groovy 6 with JDK17 minimum out before JDK11 support was phased out. It might be the case then that Groovy 4 and Groovy 6 are our "sort of LTS" versions at that point.
On Wed, May 11, 2022 at 2:22 PM J. David Beutel <l...@getsu.com> wrote: > One thing to consider is the EOL schedule, of course. Oracle > advertises[1] "extended support" for its Java customers for: > > JDK version > until > 8 > 2030* > 11 > 2026 > 17 > 2029 > > * "The Extended Support uplift fee will be waived for the period March > 2022 - December 2030 for Java SE 8. During this period, you will receive > Extended Support as described in the Oracle Technical Support Level > sections of the Technical Support Policies." > > On the other hand, Oracle's "premier support" for JDK11 ends in 2023. > > Likewise, Red Hat advertises[2] OpenJDK support for 8 until 2026, but 11 > until 2024. > > Cheers, > 11011011 > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html > [2] https://access.redhat.com/articles/1299013 > > On 2022-05-10 15:05 , 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. > > > >
