Re: Thoughts on Groovy 4 and JDK 26/27 (and Groovy 5 with 27)

I created the GROOVY_5_1_X branch and created the 5.1.0 version in
Jira - with the plan being 5.1.0 will be our next Groovy 5 release.
Please use the GROOVY_5_1_X branch for all future Groovy 5 additions.

I kept 5.0.9 in Jira, but we should use that just if we need to do
some kind of CVE where someone still needs the JApplet functionality
in Console.

Cheers, Paul.

On Tue, Jul 28, 2026 at 4:08=E2=80=AFPM Paul King <[email protected]> wrot=
e:
>
> 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=E2=80=AFAM Milles, Eric (TR Technology) via=
 dev
> <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]> wrote:
> >
> > I would stick with 4.0 and not add 4.1.  groovyConsole not working on J=
ava 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 <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[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 iter=
ate 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.