Okay, my plan is to stick with 4.0 and 5.0 version numbers for the upcoming releases, and bump the release notes to mention the console limitation on Groovy 26/27 in both cases. So, I won't touch the existing JApplet method in question right now.
I think it is far enough, as per Eric's suggestion, to refer Groovy 4 users to the working 6-beta-1 version (now) and an upcoming 5.1.0 version (when available). So, I was thinking of branching to GROOVY_5_1_X once the 5.0.8 release is out and effectively drop support for the 5_0_X line. Then we can remove the deprecated run method and that buys us another release cycle to make sure everything is right for that branch - or if things aren't panning out, it lets us back away from a 5.1 line before the next release cycle ends. Sound workable? Paul. On Tue, Jul 28, 2026 at 12:59 AM Milles, Eric (TR Technology) via dev <[email protected]> wrote: > > I would stick with 4.0 and not add 4.1. groovyConsole not working on Java > 26+ is not that big of a concession. If you want that, you have 5.0 or 6 > alpha. > ________________________________ > From: Paul King <[email protected]> > Sent: Monday, July 27, 2026 4:27 AM > To: Groovy_Developers <[email protected]> > Subject: Thoughts on Groovy 4 and JDK 26/27 (and Groovy 5 with 27) > > Hi folks, I bumped ASM on the GROOVY_4_0_X branch. I think that is the least > controversial of the changes mentioned here, but we'll do such bumps less > often as we move our focus to Groovy 6 and 7. It allows Gradle to iterate > along one more JDK > > Hi folks, > > I bumped ASM on the GROOVY_4_0_X branch. I think that is the least > controversial of the changes mentioned here, but we'll do such bumps > less often as we move our focus to Groovy 6 and 7. It allows Gradle to > iterate along one more JDK version without making the jump to a newer > Groovy version. I also added the JDK26/27 constants to > CompilerConfiguration. > > We have previously bumped the ASM version to cover JDK27 for Groovy 5. > But I also added the JDK27 constant on the GROOVY_5_0_X branch. > > Nearly everything seems to work fine under JDK26/27 except for a known > issue we have with JApplet no longer being available (removed). It is > mentioned in SwingBuilder and Console. We can get around the > SwingBuilder mention with reflection. But for Console we have a method > that has been deprecated since at least Groovy 3: > > void run(javax.swing.JApplet applet) { ... } > > While this method exists in the class, the groovyConsole won't work on JDK26+. > > We don't normally remove such methods in a patch/point release but > what do folks think of doing that for the upcoming releases. I suspect > that method hasn't been used by anyone in more than 10 years - but I > could be wrong. > > I have looked into various other options like tricking metaclass > handling to skip JApplet with nothing looking viable. The only other > option we have is to provide a method like: > > void run(java.awt.Container applet) { } > > Where Container is a super class that still exists (or we can use one > of JApplet's interfaces). This would provide a backwards runtime hook > but is still a binary breaking change, I presume for no ones benefit. > > If we think it is less of a sin to just say Console isn't compatible > with JDK26+ (it is already documented that way now), then we can leave > it as is. > > If we do remove, another option for versioning is to go 4.1.0 and > 5.1.0 as the next version numbers. > > And just for the record, all the applet stuff was removed in master > before alpha-1 I believe. > > Thoughts ? > > Paul.
