[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case, from the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8953) Imported enum causes compilation bug preventing tests from compiling
[ https://issues.apache.org/jira/browse/GROOVY-8953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774872#comment-16774872 ] Christoph Seibert commented on GROOVY-8953: --- [~daniel_sun]: I already did, see the comments above and the attachment. > Imported enum causes compilation bug preventing tests from compiling > > > Key: GROOVY-8953 > URL: https://issues.apache.org/jira/browse/GROOVY-8953 > Project: Groovy > Issue Type: Bug > Environment: JDK 8 > groovy-all:2.4.+ >Reporter: Rhys Cox >Priority: Minor > Attachments: groovy-8953.zip > > > In early December our spock tests were compiling fine, but at the start of > this year they're all breaking with the following error: > Error:Groovyc: While compiling tests of REDACTED: BUG! exception in phase > 'semantic analysis' in source unit 'REDACTEDSpec.groovy' Constructor > parameter annotations length [5] does not match the parameter length: private > REDACTEDENUMCLASS(java.lang.String,int,int,java.lang.String,ANOTHERREDACTEDENUMCLASS,java.lang.String,java.util.regex.Pattern) > at > org.codehaus.groovy.vmplugin.v5.Java5.getConstructorParameterAnnotations(Java5.java:438) > at > org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:386) > at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280) > at > org.codehaus.groovy.ast.ClassNode.getDeclaredMethods(ClassNode.java:877) > at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:892) > at > org.codehaus.groovy.ast.ClassNode.hasPossibleStaticMethod(ClassNode.java:1313) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticMethod(StaticImportVisitor.java:597) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorByFullName(StaticImportVisitor.java:565) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:532) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticFieldOrPropAccessorImportFromModule(StaticImportVisitor.java:440) > at > org.codehaus.groovy.control.StaticImportVisitor.transformVariableExpression(StaticImportVisitor.java:198) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:99) > at > org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:51) > at > org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:69) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:117) > at > org.codehaus.groovy.ast.expr.ConstructorCallExpression.transformExpression(ConstructorCallExpression.java:50) > at > org.codehaus.groovy.control.StaticImportVisitor.transformConstructorCallExpression(StaticImportVisitor.java:339) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:114) > at > org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitField(ClassCodeExpressionTransformer.java:70) > at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1073) > at > org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53) > at > org.codehaus.groovy.control.StaticImportVisitor.visitClass(StaticImportVisitor.java:78) > at > org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:692) > at > org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087) > at > org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624) > at > org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602) > at > org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579) > at > org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62) > at > org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:118) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at >
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso commented on GROOVY-9003:
--
I should have clarified better, the proposal is to skip the groovy
representation when class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8953) Imported enum causes compilation bug preventing tests from compiling
[ https://issues.apache.org/jira/browse/GROOVY-8953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774619#comment-16774619 ] Daniel Sun commented on GROOVY-8953: Could you provide some sample code to reproduce the issue? > Imported enum causes compilation bug preventing tests from compiling > > > Key: GROOVY-8953 > URL: https://issues.apache.org/jira/browse/GROOVY-8953 > Project: Groovy > Issue Type: Bug > Environment: JDK 8 > groovy-all:2.4.+ >Reporter: Rhys Cox >Priority: Minor > Attachments: groovy-8953.zip > > > In early December our spock tests were compiling fine, but at the start of > this year they're all breaking with the following error: > Error:Groovyc: While compiling tests of REDACTED: BUG! exception in phase > 'semantic analysis' in source unit 'REDACTEDSpec.groovy' Constructor > parameter annotations length [5] does not match the parameter length: private > REDACTEDENUMCLASS(java.lang.String,int,int,java.lang.String,ANOTHERREDACTEDENUMCLASS,java.lang.String,java.util.regex.Pattern) > at > org.codehaus.groovy.vmplugin.v5.Java5.getConstructorParameterAnnotations(Java5.java:438) > at > org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:386) > at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280) > at > org.codehaus.groovy.ast.ClassNode.getDeclaredMethods(ClassNode.java:877) > at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:892) > at > org.codehaus.groovy.ast.ClassNode.hasPossibleStaticMethod(ClassNode.java:1313) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticMethod(StaticImportVisitor.java:597) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorByFullName(StaticImportVisitor.java:565) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:532) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticFieldOrPropAccessorImportFromModule(StaticImportVisitor.java:440) > at > org.codehaus.groovy.control.StaticImportVisitor.transformVariableExpression(StaticImportVisitor.java:198) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:99) > at > org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:51) > at > org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:69) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:117) > at > org.codehaus.groovy.ast.expr.ConstructorCallExpression.transformExpression(ConstructorCallExpression.java:50) > at > org.codehaus.groovy.control.StaticImportVisitor.transformConstructorCallExpression(StaticImportVisitor.java:339) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:114) > at > org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitField(ClassCodeExpressionTransformer.java:70) > at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1073) > at > org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53) > at > org.codehaus.groovy.control.StaticImportVisitor.visitClass(StaticImportVisitor.java:78) > at > org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:692) > at > org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087) > at > org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624) > at > org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602) > at > org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579) > at > org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62) > at > org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:118) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at >
[jira] [Commented] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774607#comment-16774607
]
Paul King commented on GROOVY-9003:
---
I think we should do something but it may not be as simple as we'd like and
we'll need to promote it widely. For example, the following classes have their
own toString:
{noformat}
Vector, ConcurrentLinkedQueue, ArrayBlockingQueue, LinkedBlockingDeque,
LinkedBlockingQueue, PriorityBlockingQueue, LinkedTransferQueue,
SynchronousQueue
{noformat}
while these ones would normally rely on the toString from AbstractCollection
and would get the pretty Groovy representation in your proposed solution:
{noformat}
ArrayList, LinkedList, DelayQueue, PriorityQueue, ConcurrentSkipListSet,
CopyOnWriteArraySet, HashSet, TreeSet, ArrayDeque, EnumSet
{noformat}
This might not be a bad thing but will be a little unexpected for some.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8953) Imported enum causes compilation bug preventing tests from compiling
[ https://issues.apache.org/jira/browse/GROOVY-8953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774063#comment-16774063 ] Christoph Seibert commented on GROOVY-8953: --- [~paulk], [~daniel_sun]: Is there a chance for this to get a higher priority now that it is reproducible? I'm not sure why this does not come up more often, but I think it is not a small issue if it means you cannot use plain Java enums from Groovy. > Imported enum causes compilation bug preventing tests from compiling > > > Key: GROOVY-8953 > URL: https://issues.apache.org/jira/browse/GROOVY-8953 > Project: Groovy > Issue Type: Bug > Environment: JDK 8 > groovy-all:2.4.+ >Reporter: Rhys Cox >Priority: Minor > Attachments: groovy-8953.zip > > > In early December our spock tests were compiling fine, but at the start of > this year they're all breaking with the following error: > Error:Groovyc: While compiling tests of REDACTED: BUG! exception in phase > 'semantic analysis' in source unit 'REDACTEDSpec.groovy' Constructor > parameter annotations length [5] does not match the parameter length: private > REDACTEDENUMCLASS(java.lang.String,int,int,java.lang.String,ANOTHERREDACTEDENUMCLASS,java.lang.String,java.util.regex.Pattern) > at > org.codehaus.groovy.vmplugin.v5.Java5.getConstructorParameterAnnotations(Java5.java:438) > at > org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:386) > at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280) > at > org.codehaus.groovy.ast.ClassNode.getDeclaredMethods(ClassNode.java:877) > at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:892) > at > org.codehaus.groovy.ast.ClassNode.hasPossibleStaticMethod(ClassNode.java:1313) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticMethod(StaticImportVisitor.java:597) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorByFullName(StaticImportVisitor.java:565) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:532) > at > org.codehaus.groovy.control.StaticImportVisitor.findStaticFieldOrPropAccessorImportFromModule(StaticImportVisitor.java:440) > at > org.codehaus.groovy.control.StaticImportVisitor.transformVariableExpression(StaticImportVisitor.java:198) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:99) > at > org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:51) > at > org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:69) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:117) > at > org.codehaus.groovy.ast.expr.ConstructorCallExpression.transformExpression(ConstructorCallExpression.java:50) > at > org.codehaus.groovy.control.StaticImportVisitor.transformConstructorCallExpression(StaticImportVisitor.java:339) > at > org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:114) > at > org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitField(ClassCodeExpressionTransformer.java:70) > at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1073) > at > org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53) > at > org.codehaus.groovy.control.StaticImportVisitor.visitClass(StaticImportVisitor.java:78) > at > org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:692) > at > org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087) > at > org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624) > at > org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602) > at > org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579) > at > org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62) > at > org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:118) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:91) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at >
[jira] [Created] (GROOVY-9007) Getting java.lang.NoSuchFieldError with groovy version 2.5.6
Pankaj created GROOVY-9007:
--
Summary: Getting java.lang.NoSuchFieldError with groovy version
2.5.6
Key: GROOVY-9007
URL: https://issues.apache.org/jira/browse/GROOVY-9007
Project: Groovy
Issue Type: Bug
Components: class generator, groovy-runtime
Affects Versions: 2.5.6
Environment: Windows7, Java8, Spring-Boot 2.1.3
Reporter: Pankaj
Recently, I upgrade my spring boot application with version 2.1.3. I found many
test cases started failing with error {color:#d04437}(Caused by:
java.lang.NoSuchFieldError: *it*){color}. After drilling down dependency list I
noticed that groovy version 2.5.6 is being used. Which might be cauing these
issues. Earlier it was groovy version 2.5.5 and my application was working just
fine. I tried using version 2.5.5 explicitely in pom.xml and application again
started working.
This looks like a possible bug with version 2.5.6. After compaing .class file
generated for both version found some difference which might be causing this
issue:
*2.5.6 generated .class code:* Here
"TestGroovyNewVersion.AddressInd{color:#d04437}.it.{color}addressInd" looks
incorrect as 'it' not defined as var for AddressInd enum. Here 'it' isn't
getting treated as an explicit parameter for closures.
{code:java}
return
ScriptBytecodeAdapter.compareEqual(TestGroovyNewVersion.AddressInd.it.addressInd,
addressInd.get());{code}
*2.5.5 generated .class code:*
{code:java}
return
ScriptBytecodeAdapter.compareEqual(((TestGroovyNewVersion.AddressInd)it).addressInd,addressInd.get());{code}
+Here is my groovy code and below line of code is given error:+
*AddressInd indicator = values().find\{ it.addressInd == addressInd }*
{code:java}
import com.fasterxml.jackson.annotation.JsonCreator
import groovy.transform.CompileStatic
import groovy.transform.ToString
@ToString
@CompileStatic
class TestGroovyNewVersion {
private enum AddressInd {
REGISITERED_ADD('Registered add'), TRADING_ADD('Trading add'),
DELIVERY_ADD('Delivery add'), INVOICE_ADD('Invoice add')
protected String addressInd
private AddressInd(final String addressInd) {
this.addressInd = addressInd
}
@JsonCreator
static AddressInd create(final String addressInd) {
AddressInd indicator = values().find{ it.addressInd == addressInd }
if (!indicator)
{
throw new IllegalArgumentException()
}
indicator
}
}
String ref
String companyNo
String name
}{code}
I would prefer to not make code changes in my code as I have similar at too
many places at same time I don't want to use older version of groovy lib. Pls
look into matter and suggest a solution or fix this issue if it is a possible
bug in groovy 2.5.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
