[
https://issues.apache.org/jira/browse/GROOVY-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016583#comment-17016583
]
Matthias Fuchs edited comment on GROOVY-9364 at 1/16/20 6:25 AM:
-----------------------------------------------------------------
I added It because we have a compiler config that compiles everything
statically. I cannot easily change that. So this is a confirmed bug?
I decompiled the generated bug and it looks really weird to me, not what I
expected. For example a property of one object is compared to the other object.
That's a totally useless check because it can never be true. And additionally
spotbugs also reports these issues:
{code:java}
public int compareTo(WeightClassData other) {
if (other != false) {
return Integer.valueOf(0);
} else {
int value = Integer.valueOf(0);
Integer var3 = ScriptBytecodeAdapter.compareTo(this.maxWeight, other);
value = var3;
if (ScriptBytecodeAdapter.compareNotEqual(value, 0)) {
return value;
} else {
Integer var4 = ScriptBytecodeAdapter.compareTo(this.name, other);
value = var4;
if (ScriptBytecodeAdapter.compareNotEqual(value, 0)) {
return value;
} else {
Integer var5 = ScriptBytecodeAdapter.compareTo(this.code, other);
<-- MAKES NOT SENSE!?
value = var5;
return ScriptBytecodeAdapter.compareNotEqual(value, 0) ? value :
Integer.valueOf(0);
}
}
}
}
{code}
I wonder why there's even those ScriptBytecodeAdapter calls. A statically
generated code that just compares the property would be way better in that case.
was (Author: mojo2012):
I added It because we have a compiler config that compiles everything
statically. I cannot easily change that. So this is a confirmed bug?
I decompiled the generated bug and it looks really weird to me, not what I
expected. For example a property of one object is compared to the other object.
That's a totally useless check because it can never be true. And additionally
spotbugs also reports these issues:
{code:java}
public int compareTo(WeightClassData other) {
if (other != false) {
return Integer.valueOf(0);
} else {
int value = Integer.valueOf(0);
Integer var3 = ScriptBytecodeAdapter.compareTo(this.maxWeight, other);
value = var3;
if (ScriptBytecodeAdapter.compareNotEqual(value, 0)) {
return value;
} else {
Integer var4 = ScriptBytecodeAdapter.compareTo(this.name, other);
value = var4;
if (ScriptBytecodeAdapter.compareNotEqual(value, 0)) {
return value;
} else {
Integer var5 = ScriptBytecodeAdapter.compareTo(this.code, other);
<-- MAKES NOT SENSE!
value = var5;
return ScriptBytecodeAdapter.compareNotEqual(value, 0) ? value :
Integer.valueOf(0);
}
}
}
}
{code}
I wonder why there's even those ScriptBytecodeAdapter calls. A statically
generated code that just compares the property would be way better in that case.
> @Sortable not working correctly when applied to both current and super class
> ----------------------------------------------------------------------------
>
> Key: GROOVY-9364
> URL: https://issues.apache.org/jira/browse/GROOVY-9364
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.5.8
> Reporter: Matthias Fuchs
> Priority: Major
> Labels: Sortable
>
> The *compareTo* method added by the *@Sortable* annotation breaks if the
> super class also has a *@Sortable* annotation.
> Example:
>
> {code:java}
> import static org.junit.Assert.assertTrue
> import org.junit.jupiter.api.Test
> import groovy.transform.Canonical
> import groovy.transform.CompileStatic
> import groovy.transform.Sortable
> @CompileStatic
> public class BeanSortingTest {
> private int compare(Object o1, Object o2) {
> return ((Comparable) o1).compareTo((Comparable) o2)
> }
> @Test
> void testTestData() {
> def t1 = new TestData(code: 100)
> def t2 = new TestData(code: 200)
> def c1 = new TestChild(value: 10, code: 10)
> def c2 = new TestChild(value: 20, code: 10)
> checkComparison(t1, t2)
> checkComparison(c1, c2) <--- FAILS HERE
> }
> private void checkComparison(Object o1, Object o2) {
> assertTrue(compare(o1, o2) == -1)
> assertTrue(o1.equals(o2) == false)
> }
> @Canonical
> @Sortable(includes = [ "code" ])
> public static class TestData {
> Integer code
> }
> @Canonical
> @Sortable(includes = [ "value" ], includeSuperProperties = true)
> public static class TestChild extends TestData {
> Double value
> }
> }
> {code}
> What happens is that the *compareTo* of the super class is invoked, which
> only compare the *code* property. In this case both objects have the same
> value set for *code*.
>
> In fact the sub types *compareTo* method should be used primarily and only
> after that the code field of the super class should be compared. It seems
> that the super type's compareTo is invoked instead as this sort c1 first
> (although value is higher:
>
> {code:java}
> def c1 = new TestChild(value: 30, code: 10)
> def c2 = new TestChild(value: 20, code: 20){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
