Thank you Paul. On Fri, Apr 11, 2025 at 10:03 PM Paul King <pa...@asert.com.au> wrote:
> Git bisect shows it as the following commit causing the change in behavior: > > https://github.com/apache/groovy/commit/09247dd06d > > None of the mentioned issues have 3.0.23 added to the fix version, so > they don't appear in the 3.0.23 release notes, but maybe it wasn't the > whole fix that was backported. It's always hard backporting fixes. I > suspect it was an unintended side effect of those changes for the > static field generics to be flagged. Having said that, it is illegal > code in Java, Groovy has just been previously ignoring the error and > treating it like "Object". > > It isn't necessarily obvious from your examples but if you had: > > class Wrapper<T> { > static final T someConst > } > > Then Wrapper<String> and Wrapper<Integer> would have dramatically > different ideas about what the shared constant's type is. That's why > Java flags it as an error. Earlier Groovy versions just ignored that > and treated the constant as type Object. We could debate whether this > should have happened in a point release, or only for type checked > code, but it's only bad code that is affected, so I don't think we > want to change now. > > I'd suggest just fixing any impacted code, e.g. either changing to an > instance field: > > private final Closure<T> noOpClosure = { T v -> return v } > > Or use a static factory method (the T method placeholder here is > unrelated to the class generics): > > private static final <T> Closure<T> getNoOpClosure() { > { T v -> return v } > } > > > Paul. > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > Virus-free.www.avast.com > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > > On Sat, Apr 12, 2025 at 3:43 AM James Daugherty > <jdaughe...@jdresources.net> wrote: > > > > Hello Everyone, > > > > Grails recently had a bug report on one of the upgrades in 6.x. > https://github.com/apache/grails-core/issues/14130#issuecomment-2797619047 > > > > I've narrowed down the issue to the groovy upgrade from 3.0.21 to > 3.0.23. In groovy 3.0.21 the following code compiles: > > > > class GenericWrapper<T> { > > > > private static final Closure<T> noOpClosure = { T v -> return v } > > > > private T obj > > > > GenericWrapper(T obj) { > > this.obj = obj > > } > > > > T transformObj() { > > return noOpClosure.call(this.obj) > > } > > > > } > > > > While in groovy 3.0.23 it fails to compile with: > > > > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup > failed: > > testing.groovy: 3: unable to resolve class T > > @ line 3, column 31. > > private static final Closure<T> noOpClosure = { T v -> return v } > > ^ > > > > testing.groovy: 3: unable to resolve class T > > @ line 3, column 50. > > al Closure<T> noOpClosure = { T v -> ret > > ^ > > > > 2 errors > > > > > > Is anyone aware of a known regression in this area? > > > > Regards, > > James > > >
