Integer / Long comparison
in [Java Help]
|
Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME
From: Lew on 11 Sep 2009 13:56 grz01 says... >>> In JUnit I want to compare an Integer with a Long, as 2 Integers -- >>> say like this: > >>> Integer i = ...; >>> Long l = ...; >>> assertEquals(i,l); // assertEquals is ambigous, doesnt work > Pitch wrote: >> Maybe you should redesign the code so they are the same type. > Morris Keesan wrote: > or simply sidestep the issue by replacing the assertEquals with > assertTrue(i == l); > That will always fail since it will always be true that 'eye != ell'. (I changed the variable names from 'i' to 'eye' and from 'l' to 'ell' for readability because 'l' looks too much like '1'.) -- Lew
From: John B. Matthews on 11 Sep 2009 14:15 In article <46b124df-ae8d-47ef-9376-855d809d7cf6(a)r39g2000yqm.googlegroups.com>, Lew <lew(a)lewscanon.com> wrote: > grz01 says... > >>> In JUnit I want to compare an Integer with a Long, as 2 Integers -- > >>> say like this: > > > >>> Integer i = ...; > >>> Long l = ...; > >>> assertEquals(i,l); // assertEquals is ambigous, doesnt work > > > > Pitch wrote: > >> Maybe you should redesign the code so they are the same type. > > > > Morris Keesan wrote: > > or simply sidestep the issue by replacing the assertEquals with > > assertTrue(i == l); > > > > That will always fail since it will always be true that 'eye != ell'. That was my first thought, but the compiler sees they are "incomparable types." Casting to the abstract superclass fails as expected: Assert.assertTrue((Number)eye == (Number)ell); > (I changed the variable names from 'i' to 'eye' and from 'l' to 'ell' > for readability because 'l' looks too much like '1'.) Agreed. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Lew on 11 Sep 2009 14:43 Morris Keesan wrote: >>> or simply sidestep the issue by replacing the assertEquals with >>> assertTrue(i == l); > Lew wrote: >> That will always fail since it will always be true that 'eye != ell'. > John B. Matthews wrote: > That was my first thought, but the compiler sees they are "incomparable > types." > That, too, is failure, of a different kind. > Casting to the abstract superclass fails as expected: > Assert.assertTrue((Number)eye == (Number)ell); > Either way, direct comparison of the object references via '==' is not the right approach. -- Lew
From: markspace on 11 Sep 2009 15:14 John B. Matthews wrote: > > That was my first thought, but the compiler sees they are "incomparable > types." Casting to the abstract superclass fails as expected: I had no idea the compiler would spot that. Thanks for point this out!
From: Pitch on 11 Sep 2009 17:31
In article <h8dgjr$67p$1(a)news.albasani.net>, noone(a)lewscanon.com says... > > grz01 says... > >> In JUnit I want to compare an Integer with a Long, as 2 Integers -- > >> say like this: > >> > >> Integer i = ...; > >> Long l = ...; > >> assertEquals(i,l); // assertEquals is ambigous, doesnt work > > Pitch wrote: > > Maybe you should redesign the code so they are the same type. > > grz01 already told us two days ago: > > This was a simplified example I wrote only to demonstrate the problem, > > but in the actual code I have here, the objects and types come from > > third-party frameworks we are using, so I cant use your advice re. int/ > > long, etc. > > The Integer and Long types are what they are and cannot be changed. So if both types are from a third party, there is nothing he can do about the performance, but read the documentation and choose what's the best aproach to keep data integrity. -- stirr your cofee |