groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8806) Immutable classes break in groovy 2.5.2
Date Wed, 03 Oct 2018 07:11:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636538#comment-16636538
] 

Paul King commented on GROOVY-8806:
-----------------------------------

I have sent an email to the dev list but to re-iterate:

{quote}
I have a potential fix for this issue. I'd appreciate if anyone who has had issues could apply
the PR and see if it fixes their problems:

https://github.com/apache/groovy/pull/803

For anyone who has dived into the current implementation, they will know that currently a
collector annotation definition is converted into a helper class of sorts containing the serialized
annotation data so that pre-compiled meta-annotations can be processed.
Basically the fix allows the original annotation to be left in the codebase and instead creates
an inner helper class with the serialized data and a reference to the class in an annotation
attribute called serializeClass on AnnotationCollector.
I don't face the issue described in GROOVY-8806 when using Groovy 2.5.2 normally with asmResolving
in place, I only see it when using classloader resolution. The proposed fix works for either
and is backwards compatible with 2.4.x and 2.5.2 and earlier.
My cross version testcase which isn't covered by existing tests is to create an immutable
class in 2.5.3-SNAPSHOT that references a property with a 2.4.15 compiled @Immutable type
and another with a 2.5.2 compiled @Immutable type and compile it up with asmResolving set
to false.

Normally, serializeClass is set automatically for you as part of AnnotationCollector processing
but there is also a fallback to the existing behavior by explicitly setting the serializeClass
to the collector annotation. So in the following example, Foo will use the new approach and
Bar the current one as per 2.5.2.

@AnnotationCollector
@ToString
@interface Foo { }

@AnnotationCollector(serializeClass=Bar)
@EqualsAndHashCode
@interface Bar { }

Currently, the proposal makes the new approach the default. Any feedback welcome.
{quote}

> Immutable classes break in groovy 2.5.2
> ---------------------------------------
>
>                 Key: GROOVY-8806
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8806
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.5.2
>            Reporter: Roberto Perez Alcolea
>            Priority: Major
>
> We've being running tests of gradle plugins with latest gradle nightly release which
upgraded to groovy 2.5.2
> Since then, we've seen multiple plugins breaking with errors around immutability:
>  
> {code:java}
> > Unsupported type (org.ajoberstar.grgit.Branch) found for field 'trackingBranch'
while constructing immutable class org.ajoberstar.grgit.Branch.
> Immutable classes only support properties with effectively immutable types including:
> - Strings, primitive types, wrapper types, Class, BigInteger and BigDecimal, enums
> - classes annotated with @KnownImmutable and known immutables (java.awt.Color, java.net.URI)
> - Cloneable classes, collections, maps and arrays, and other classes with special handling
> (java.util.Date and various java.time.* classes and interfaces)
> Other restrictions apply, please see the groovydoc for ImmutableOptions for further details{code}
>  
> I was wondering if this change is related to [https://github.com/apache/groovy/commit/3471f55ea5839ab3c9dfa51cdca081bc7b4c020e#diff-8f745c460bc1abf332f21067b21ec551R754] 
>  
> And also,  looks like gradle plugins that use the gradleApi and are compiled with groovy
2.4 could break with groovy 2.5 with usages like this one



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message