[jira] [Commented] (GROOVY-7291) Declaration of double variable without value assignment referrenced in closure

2016-07-25 Thread John Wagenleitner (JIRA) 

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

John Wagenleitner commented on GROOVY-7291:
---

Based on feedback in the PR I closed it, since it didn't seem to be the right 
fix.

> Declaration of double variable without value assignment referrenced in closure
> --
>
> Key: GROOVY-7291
> URL: https://issues.apache.org/jira/browse/GROOVY-7291
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 1.8.6, 2.2.1, 2.4.0
> Environment: Windows 8.1, JDK 1.7_71 and 1.8_25
>Reporter: David Richter
>Priority: Critical
> Attachments: groovyBug.zip
>
>
> I have problem with following code:
> {code}
> double a;
> def b = {
>a = a + 1;
> }
> b();
> {code}
> I tried to compile it with groovy 1.8.6 and it worked 
> variable 'a' was instantiated with value 0.0
> but after upgrade to groovy 2.2.1
> it throws NullPointerException because variable 'a' is instantiated to null
> I tried to decompile class files and declaration of 'a' looked like this:
> version 1.8.6
> {noformat}
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new 
> Reference((Double)DefaultTypeTransformation.box(0.0D));
> DefaultTypeTransformation.doubleUnbox(a.get());
> ...
> {noformat}
> version 2.2.1
> {noformat}
> CallSite[] var1 = $getCallSiteArray();
> final Reference a = new Reference((Object)null);
> Double var1 = (Double)a.get();
> ...
> {noformat}
> I tried it also with version 2.4.0 but it has same result as 2.2.1
> In attachment are groovy classes, compiled classes and consoleOutputs for 
> versions 1.8.6 and 2.2.1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] groovy pull request #331: GROOVY-7291 - Declaration of double variable witho...

2016-07-25 Thread jwagenleitner 
Github user jwagenleitner closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (GROOVY-7892) CLONE - ClassCastException when calling DefaultTypeTransformation#compareEqual

2016-07-25 Thread Paul King (JIRA) 
Paul King created GROOVY-7892:
-

 Summary: CLONE - ClassCastException when calling 
DefaultTypeTransformation#compareEqual
 Key: GROOVY-7892
 URL: https://issues.apache.org/jira/browse/GROOVY-7892
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.4.6
Reporter: Andrew White
Assignee: Paul King
 Fix For: 2.4.8


It appears that comparing two objects that both implement comparable with 
DefaultTypeTransformation#compareEqual is not safe in all cases. Consider enums 
for example, which throw exceptions when compared to differing classes. 

This is using Eclipse Collections for pairs but the idea is the same in 
general. 

{code}
enum E1 {A, B, C}
enum E2 {D, E, F}

def "test groovy oddness"() {
when:
def test = DefaultTypeTransformation.compareEqual(
Tuples.pair(E1.A, 1), 
Tuples.pair(E2.D, 1))

then:
assert test == false
}
{code}

Stacktrace

{code}
java.lang.ClassCastException
at java.lang.Enum.compareTo(Enum.java:180)
at java.lang.Enum.compareTo(Enum.java:55)
at 
org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:95)
at 
org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:22)
at com.GroovyTests.test groovy oddness(GroovyTests.groovy:36)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GROOVY-7892) CLONE - ClassCastException when calling DefaultTypeTransformation#compareEqual

2016-07-25 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King resolved GROOVY-7892.
---
   Resolution: Fixed
Fix Version/s: (was: 2.4.8)
   2.5.0-beta-1

As part of fixing the cloned issue, we also changed the exception returned for 
the relevant code when comparing using compareTo. The now thrown 
IllegalArgumentException is more informative but is a breaking change if you 
were expecting the previous ClassCastException which is now the cause of the 
new exception. This was done for 2.5+ only.

> CLONE - ClassCastException when calling DefaultTypeTransformation#compareEqual
> --
>
> Key: GROOVY-7892
> URL: https://issues.apache.org/jira/browse/GROOVY-7892
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.6
>Reporter: Andrew White
>Assignee: Paul King
> Fix For: 2.5.0-beta-1
>
>
> It appears that comparing two objects that both implement comparable with 
> DefaultTypeTransformation#compareEqual is not safe in all cases. Consider 
> enums for example, which throw exceptions when compared to differing classes. 
> This is using Eclipse Collections for pairs but the idea is the same in 
> general. 
> {code}
> enum E1 {A, B, C}
> enum E2 {D, E, F}
> def "test groovy oddness"() {
> when:
> def test = DefaultTypeTransformation.compareEqual(
> Tuples.pair(E1.A, 1), 
> Tuples.pair(E2.D, 1))
> then:
> assert test == false
> }
> {code}
> Stacktrace
> {code}
> java.lang.ClassCastException
>   at java.lang.Enum.compareTo(Enum.java:180)
>   at java.lang.Enum.compareTo(Enum.java:55)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:95)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:22)
>   at com.GroovyTests.test groovy oddness(GroovyTests.groovy:36)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GROOVY-7876) ClassCastException when calling DefaultTypeTransformation#compareEqual

2016-07-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on GROOVY-7876:


Github user asfgit closed the pull request at:

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


> ClassCastException when calling DefaultTypeTransformation#compareEqual
> --
>
> Key: GROOVY-7876
> URL: https://issues.apache.org/jira/browse/GROOVY-7876
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.6
>Reporter: Andrew White
>Assignee: Paul King
> Fix For: 2.4.8
>
>
> It appears that comparing two objects that both implement comparable with 
> DefaultTypeTransformation#compareEqual is not safe in all cases. Consider 
> enums for example, which throw exceptions when compared to differing classes. 
> This is using Eclipse Collections for pairs but the idea is the same in 
> general. 
> {code}
> enum E1 {A, B, C}
> enum E2 {D, E, F}
> def "test groovy oddness"() {
> when:
> def test = DefaultTypeTransformation.compareEqual(
> Tuples.pair(E1.A, 1), 
> Tuples.pair(E2.D, 1))
> then:
> assert test == false
> }
> {code}
> Stacktrace
> {code}
> java.lang.ClassCastException
>   at java.lang.Enum.compareTo(Enum.java:180)
>   at java.lang.Enum.compareTo(Enum.java:55)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:95)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:22)
>   at com.GroovyTests.test groovy oddness(GroovyTests.groovy:36)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] groovy pull request #372: GROOVY-7876 - ClassCastException when calling Defa...

2016-07-25 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GROOVY-7876) ClassCastException when calling DefaultTypeTransformation#compareEqual

2016-07-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on GROOVY-7876:


GitHub user paulk-asert opened a pull request:

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

GROOVY-7876 - ClassCastException when calling DefaultTypeTransformati…

…on#compareEqual (additional refactoring)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/groovy groovy7876b

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/372.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #372


commit 65362bdfad86cc785a9fa039a58d512beabff032
Author: paulk 
Date:   2016-07-25T14:53:39Z

GROOVY-7876 - ClassCastException when calling 
DefaultTypeTransformation#compareEqual (additional refactoring)




> ClassCastException when calling DefaultTypeTransformation#compareEqual
> --
>
> Key: GROOVY-7876
> URL: https://issues.apache.org/jira/browse/GROOVY-7876
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.6
>Reporter: Andrew White
>Assignee: Paul King
> Fix For: 2.4.8
>
>
> It appears that comparing two objects that both implement comparable with 
> DefaultTypeTransformation#compareEqual is not safe in all cases. Consider 
> enums for example, which throw exceptions when compared to differing classes. 
> This is using Eclipse Collections for pairs but the idea is the same in 
> general. 
> {code}
> enum E1 {A, B, C}
> enum E2 {D, E, F}
> def "test groovy oddness"() {
> when:
> def test = DefaultTypeTransformation.compareEqual(
> Tuples.pair(E1.A, 1), 
> Tuples.pair(E2.D, 1))
> then:
> assert test == false
> }
> {code}
> Stacktrace
> {code}
> java.lang.ClassCastException
>   at java.lang.Enum.compareTo(Enum.java:180)
>   at java.lang.Enum.compareTo(Enum.java:55)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:95)
>   at 
> org.eclipse.collections.impl.tuple.PairImpl.compareTo(PairImpl.java:22)
>   at com.GroovyTests.test groovy oddness(GroovyTests.groovy:36)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] groovy pull request #372: GROOVY-7876 - ClassCastException when calling Defa...

2016-07-25 Thread paulk-asert 
GitHub user paulk-asert opened a pull request:

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

GROOVY-7876 - ClassCastException when calling DefaultTypeTransformati…

…on#compareEqual (additional refactoring)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/groovy groovy7876b

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/372.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #372


commit 65362bdfad86cc785a9fa039a58d512beabff032
Author: paulk 
Date:   2016-07-25T14:53:39Z

GROOVY-7876 - ClassCastException when calling 
DefaultTypeTransformation#compareEqual (additional refactoring)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GROOVY-7608) Comparison of decimal subclasses of Number with == fails

2016-07-25 Thread Paul King (JIRA) 

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

Paul King commented on GROOVY-7608:
---

If you could check whether the fix for GROOVY-7636 also fixes your issue, that 
would be great.

> Comparison of decimal subclasses of Number with == fails
> 
>
> Key: GROOVY-7608
> URL: https://issues.apache.org/jira/browse/GROOVY-7608
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Sean Gilligan
>
> If I create a subclass of {{Number}} that is implemented internally with a 
> decimal value, e.g. using a {{BigDecimal}} even if I implement 
> {{compareTo()}}, Groovy will convert my numbers to {{Integer}} before 
> comparison.
> {code}
> given:
> def one = MyNumberSubclass.of(1)
> def oneptone = MyNumberSubclass.of(1.1)
> then:
> one == onptone  // passes when it shouldn't!
> oneptone == oneptone// fails when it shouldn't!
> {code}
> This is a critical issue for anyone creating a DSL that has custom numeric 
> types (e.g. for currency handling) and wants to compare them with {{==}}.
> Specifically this problem occurs with implementations of {{NumberValue}} in 
> JSR354 aka *JavaMoney*.
> I can provide some test cases for this if needed and am interesting in 
> working to contribute a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (GROOVY-7636) NumberMath.getMath suboptimal choice for custom Numbers

2016-07-25 Thread Paul King (JIRA) 

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

Paul King edited comment on GROOVY-7636 at 7/25/16 10:07 AM:
-

PR merged, thanks! I wasn't intending to port back to the 2_4_X branch but let 
me know if you feel strongly about that decision.


was (Author: paulk):
PR merged, thanks

> NumberMath.getMath suboptimal choice for custom Numbers
> ---
>
> Key: GROOVY-7636
> URL: https://issues.apache.org/jira/browse/GROOVY-7636
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-jdk
>Reporter: Thibault Kruse
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-beta-1
>
>
> When implementing the java.lang.Number interface with a custom class, the 
> groovy NumberMath class file's instanceof check do not find a math, and it 
> defaults to IntegerMath. I believe the default should be BigDecimal for 
> best-effort compatibility.
> Also when comparing BigDecimal to a true Float or Double, FloatingPointMath 
> is used, not BigDecimalMath.
> to reproduce:
> {code}  
> static class MyNumber extends Number {
> def n
> MyNumber(n) {
> this.n = n
> }
> int intValue(){n}
> long longValue(){n}
> float floatValue(){n}
> double doubleValue(){n}
> int hashCode(){-n}
> boolean equals(other) {
> if (other instanceof MyNumber) { return n==other.n}
> return false
> }
> String toString() {return Double.toString(floatValue())}
> }
> void testGetMathCustom() {
> //assert getMath(50.0G, Float.valueOf("1.0")) == 
> BigDecimalMath.INSTANCE;
> //assert getMath(50G, Float.valueOf("1.0")) == 
> BigDecimalMath.INSTANCE;
> MyNumber num = new MyNumber(42);
> assert getMath(num) == BigDecimalMath.INSTANCE;
> assert getMath(num, 25) == BigDecimalMath.INSTANCE;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (GROOVY-7636) NumberMath.getMath suboptimal choice for custom Numbers

2016-07-25 Thread Paul King (JIRA) 

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

Paul King edited comment on GROOVY-7636 at 7/25/16 10:07 AM:
-

PR merged, thanks! I wasn't intending to port back to the 2_4_X branch but let 
me know if you feel strongly about that intention.


was (Author: paulk):
PR merged, thanks! I wasn't intending to port back to the 2_4_X branch but let 
me know if you feel strongly about that decision.

> NumberMath.getMath suboptimal choice for custom Numbers
> ---
>
> Key: GROOVY-7636
> URL: https://issues.apache.org/jira/browse/GROOVY-7636
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-jdk
>Reporter: Thibault Kruse
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-beta-1
>
>
> When implementing the java.lang.Number interface with a custom class, the 
> groovy NumberMath class file's instanceof check do not find a math, and it 
> defaults to IntegerMath. I believe the default should be BigDecimal for 
> best-effort compatibility.
> Also when comparing BigDecimal to a true Float or Double, FloatingPointMath 
> is used, not BigDecimalMath.
> to reproduce:
> {code}  
> static class MyNumber extends Number {
> def n
> MyNumber(n) {
> this.n = n
> }
> int intValue(){n}
> long longValue(){n}
> float floatValue(){n}
> double doubleValue(){n}
> int hashCode(){-n}
> boolean equals(other) {
> if (other instanceof MyNumber) { return n==other.n}
> return false
> }
> String toString() {return Double.toString(floatValue())}
> }
> void testGetMathCustom() {
> //assert getMath(50.0G, Float.valueOf("1.0")) == 
> BigDecimalMath.INSTANCE;
> //assert getMath(50G, Float.valueOf("1.0")) == 
> BigDecimalMath.INSTANCE;
> MyNumber num = new MyNumber(42);
> assert getMath(num) == BigDecimalMath.INSTANCE;
> assert getMath(num, 25) == BigDecimalMath.INSTANCE;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GROOVY-7600) @Immutable support for Optional?

2016-07-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on GROOVY-7600:


Github user paulk-asert closed the pull request at:

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


> @Immutable support for Optional?
> 
>
> Key: GROOVY-7600
> URL: https://issues.apache.org/jira/browse/GROOVY-7600
> Project: Groovy
>  Issue Type: Improvement
>Affects Versions: 2.4.4
>Reporter: Christopher Smith
>Assignee: Paul King
>
> The {{@Immutable}} transform does not have any particular understanding of 
> {{java.util.Optional}}. The holder class itself is immutable, but the logical 
> immutability depends on the contained type. It would be helpful for 
> {{@Immutable}} to understand such holder types and do its sanity check on the 
> generic type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] groovy pull request #151: GROOVY-7636: Fall back to BigDecimalMath for custo...

2016-07-25 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (GROOVY-7637) DefaultTypeTransformation.compareTo not symmetrical

2016-07-25 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King resolved GROOVY-7637.
---
   Resolution: Fixed
 Assignee: Paul King
Fix Version/s: 2.5.0-beta-1

PR merged with some minor tweaks. Thanks!

> DefaultTypeTransformation.compareTo not symmetrical
> ---
>
> Key: GROOVY-7637
> URL: https://issues.apache.org/jira/browse/GROOVY-7637
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-jdk
>Reporter: Thibault Kruse
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-beta-1
>
>
> DefaultTypeTransformation.compareTo(Object left, Object right) is being used 
> in plenty of places in Groovy.
> However, for several corner cases, it does not provide symmetry, that is: 
> when compareTo(a, b) returns a value (does not fail), then:
> signum(compareTo(a, b)) == - signum(compareTo(b, a))
> To reproduce:
> {code}
>   static class MyNumber extends Number {
> def n
> MyNumber(n) {
> this.n = n
> }
> int intValue(){n}
> long longValue(){n}
> float floatValue(){n}
> double doubleValue(){n}
> int hashCode(){-n}
> boolean equals(other) {
> if (other instanceof MyNumber) { return n==other.n}
> return false
> }
> String toString() {n.toString()}
> }
> static class MyNumberCompareTo extends MyNumber {
> MyNumberCompareTo(Object n) {
> super(n)
> }
> int compareTo(MyNumber other) {
> return n <=> other.n
> }
> }
> static class MyNumberComparable extends MyNumberCompareTo implements 
> Comparable {
> MyNumberComparable(Object n) {
> super(n)
> }
> int compareTo(Object other) {
> return n <=>  (MyNumber) other;
> }
> }
> void testCompareTo() {
> def object1 = new Object()
> def object2 = new Object()
> // objects
> assert compareTo(null, null) == 0
> assert compareTo(object1, null) == 1
> assert compareTo(null, object1) == -1
> assert compareTo(1, 1) == 0
> shouldFail(GroovyRuntimeException) {
> compareTo(object1, object2)
> }
> // chars, int values 49 and 50
> Character char1 = '1' as Character
> Character char2 = '2' as Character
> checkCompareToSymmetricSmallerThan(char1, char2)
> MyNumber number1 = new MyNumber(49)
> MyNumber number2 = new MyNumber(50)
> MyNumberCompareTo numCompTo1 = new MyNumberCompareTo(49)
> MyNumberCompareTo numCompTo2 = new MyNumberCompareTo(50)
> MyNumberComparable numComp1 = new MyNumberComparable(49)
> MyNumberComparable numComp2 = new MyNumberComparable(50)
> List lowers = [49, 49L, 49.0, 49.0G, 49.00G, char1, '1', number1, 
> numCompTo1, numComp1]
> List highers = [50, 50L, 50.0, 50.0G, 50.00G, char2, '2', number2, 
> numCompTo2, numComp2]
> lowers.each { def lower ->
> assert compareTo(lower, lower) == 0
> highers.each { def higher ->
> checkCompareToSymmetricSmallerThan(lower, higher)
> }
> }
> // glitch, failing with ClassCastException
> shouldFail(GroovyRuntimeException) {
> compareTo(1, "22")
> }
> shouldFail(GroovyRuntimeException) {
> compareTo("22", 1)
> }
> // strings and chars
> assert compareTo('aa1', '2' as Character) > 0
> // bug, classCast exception
> assert compareTo('2' as Character, 'aa1') < 0
> assert compareTo("aa${1}", '2' as Character) > 0
> // bug, classCast exception
> assert compareTo('2' as Character, "aa${1}") < 0
> // Strings and GStrings
> List lowers2 = ['aa1', "aa${1}"]
> List highers2 = ['bb2', "b${2}"]
> lowers2.each { def lower ->
> assert compareTo(lower, lower) == 0
> highers2.each { def higher ->
> checkCompareToSymmetricSmallerThan(lower, higher)
> }
> }
> }
> static void checkCompareToSymmetricSmallerThan(a, b) {
> try {
> assert compareTo(a, b) < 0
> assert compareTo(b, a) > 0
> } catch (AssertionError e) {
> System.err.print(a.class.toString() + ' compared to ' + 
> b.class.toString() )
> throw e
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GROOVY-7637) DefaultTypeTransformation.compareTo not symmetrical

2016-07-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on GROOVY-7637:


Github user asfgit closed the pull request at:

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


> DefaultTypeTransformation.compareTo not symmetrical
> ---
>
> Key: GROOVY-7637
> URL: https://issues.apache.org/jira/browse/GROOVY-7637
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-jdk
>Reporter: Thibault Kruse
>Priority: Minor
>
> DefaultTypeTransformation.compareTo(Object left, Object right) is being used 
> in plenty of places in Groovy.
> However, for several corner cases, it does not provide symmetry, that is: 
> when compareTo(a, b) returns a value (does not fail), then:
> signum(compareTo(a, b)) == - signum(compareTo(b, a))
> To reproduce:
> {code}
>   static class MyNumber extends Number {
> def n
> MyNumber(n) {
> this.n = n
> }
> int intValue(){n}
> long longValue(){n}
> float floatValue(){n}
> double doubleValue(){n}
> int hashCode(){-n}
> boolean equals(other) {
> if (other instanceof MyNumber) { return n==other.n}
> return false
> }
> String toString() {n.toString()}
> }
> static class MyNumberCompareTo extends MyNumber {
> MyNumberCompareTo(Object n) {
> super(n)
> }
> int compareTo(MyNumber other) {
> return n <=> other.n
> }
> }
> static class MyNumberComparable extends MyNumberCompareTo implements 
> Comparable {
> MyNumberComparable(Object n) {
> super(n)
> }
> int compareTo(Object other) {
> return n <=>  (MyNumber) other;
> }
> }
> void testCompareTo() {
> def object1 = new Object()
> def object2 = new Object()
> // objects
> assert compareTo(null, null) == 0
> assert compareTo(object1, null) == 1
> assert compareTo(null, object1) == -1
> assert compareTo(1, 1) == 0
> shouldFail(GroovyRuntimeException) {
> compareTo(object1, object2)
> }
> // chars, int values 49 and 50
> Character char1 = '1' as Character
> Character char2 = '2' as Character
> checkCompareToSymmetricSmallerThan(char1, char2)
> MyNumber number1 = new MyNumber(49)
> MyNumber number2 = new MyNumber(50)
> MyNumberCompareTo numCompTo1 = new MyNumberCompareTo(49)
> MyNumberCompareTo numCompTo2 = new MyNumberCompareTo(50)
> MyNumberComparable numComp1 = new MyNumberComparable(49)
> MyNumberComparable numComp2 = new MyNumberComparable(50)
> List lowers = [49, 49L, 49.0, 49.0G, 49.00G, char1, '1', number1, 
> numCompTo1, numComp1]
> List highers = [50, 50L, 50.0, 50.0G, 50.00G, char2, '2', number2, 
> numCompTo2, numComp2]
> lowers.each { def lower ->
> assert compareTo(lower, lower) == 0
> highers.each { def higher ->
> checkCompareToSymmetricSmallerThan(lower, higher)
> }
> }
> // glitch, failing with ClassCastException
> shouldFail(GroovyRuntimeException) {
> compareTo(1, "22")
> }
> shouldFail(GroovyRuntimeException) {
> compareTo("22", 1)
> }
> // strings and chars
> assert compareTo('aa1', '2' as Character) > 0
> // bug, classCast exception
> assert compareTo('2' as Character, 'aa1') < 0
> assert compareTo("aa${1}", '2' as Character) > 0
> // bug, classCast exception
> assert compareTo('2' as Character, "aa${1}") < 0
> // Strings and GStrings
> List lowers2 = ['aa1', "aa${1}"]
> List highers2 = ['bb2', "b${2}"]
> lowers2.each { def lower ->
> assert compareTo(lower, lower) == 0
> highers2.each { def higher ->
> checkCompareToSymmetricSmallerThan(lower, higher)
> }
> }
> }
> static void checkCompareToSymmetricSmallerThan(a, b) {
> try {
> assert compareTo(a, b) < 0
> assert compareTo(b, a) > 0
> } catch (AssertionError e) {
> System.err.print(a.class.toString() + ' compared to ' + 
> b.class.toString() )
> throw e
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)