Re: Thoughts on Groovy 4 and JDK 26/27 (and Groovy 5 with 27)
"Milles, Eric (TR Technology) via dev" <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]> Mon, 27 Jul 2026 14:59:03 +0000
| Newsgroups | gmane.comp.lang.groovy.devel |
|---|---|
| Message-ID | <PH7PR03MB722424551B448FCC8A32D5068ACC2@PH7PR03MB7224.namprd03.prod.outlook.com> |
--_000_PH7PR03MB722424551B448FCC8A32D5068ACC2PH7PR03MB7224namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 a= lpha. ________________________________ 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 leas= t 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 JDK2= 6+. 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. --_000_PH7PR03MB722424551B448FCC8A32D5068ACC2PH7PR03MB7224namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, = Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas= s=3D"elementToProof"> 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.</div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Paul King <paulk@a= sert.com.au><br> <b>Sent:</b> Monday, July 27, 2026 4:27 AM<br> <b>To:</b> Groovy_Developers <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]><br> <b>Subject:</b> Thoughts on Groovy 4 and JDK 26/27 (and Groovy 5 with 27)</= font> <div> </div> </div> <div> <div style=3D"display:none!important; display:none; visibility:hidden; font= -size:1px; color:#ffffff; line-height:1px; max-height:0px; opacity:0; overf= low:hidden"> Hi folks, I bumped ASM on the GROOVY_4_0_X branch. I think that is the leas= t 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</div> <div style=3D"display:none!important; display:none; visibility:hidden; font= -size:1px; color:#ffffff; line-height:1px; max-height:0px; opacity:0; overf= low:hidden"> </div> <style> <!-- #x_pfptBanner1i8xte6 {display:block!important; visibility:visible!important; opacity:1!important; background-color:#d0d8dc!important; max-width:none!important; max-height:none!important} html:root, html:root > div {display:block!important; visibility:visible!important; opacity:1!important} --> </style> <pre style=3D"font-family:sans-serif; font-size:100%; white-space:pre-wrap;= word-wrap:break-word">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 JDK2= 6+. 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. </pre> </div> </body> </html> --_000_PH7PR03MB722424551B448FCC8A32D5068ACC2PH7PR03MB7224namp_--