Integer / Long comparison
in [Java Help]
|
Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME
From: Lew on 11 Sep 2009 18:16 Pitch wrote: >>> Maybe you should redesign the code so they are the same type. > Lew wrote: >> grz01 already told us: >>> 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. > Pitch wrote: > 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. > There isn't a performance issue here in the first place. Since the types are from a third party, there's nothing the OP can do about that choice regardless of whether it's a performance, productivity or integrity issue, but work with the types given him. -- Lew
From: Mike Schilling on 11 Sep 2009 19:26 Lew wrote: > Pitch wrote: >>>> Maybe you should redesign the code so they are the same type. >> > > Lew wrote: >>> grz01 already told us: >>>> 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. >> > > Pitch wrote: >> 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. >> > > There isn't a performance issue here in the first place. > > Since the types are from a third party, there's nothing the OP can > do > about that choice regardless of whether it's a performance, > productivity or integrity issue, but work with the types given him. The simplest way to do this, I suspect, is to 1. subclass TestCase.(to, say, TestCaseWithBloodyStupidBoxedTypes) 2. implement all needed assertEquals() overloads in this subclass 3. derive all the unit tests from the subclass Now, when a test calls assertEquals(Boolean, Quaternion), it'll find an exact match.
From: markspace on 11 Sep 2009 20:59 Mike Schilling wrote: > Now, when a test calls assertEquals(Boolean, Quaternion), it'll find > an exact match. I think the OP could just make one assertEquals( Object, Object ) method, and call the toString of each object. Then compare based on the strings.
From: Lew on 11 Sep 2009 21:16 Mike Schilling wrote: >> Now, when a test calls assertEquals(Boolean, Quaternion), it'll find >> an exact match. markspace wrote: > I think the OP could just make one assertEquals( Object, Object ) > method, and call the toString of each object. Then compare based on the > strings. Given his attention to micro-optimization upthread, he might prefer Patricia's recommendation to use longValue() on the Integer and Long arguments. Given the simplicity of the longValue() approach, I know I prefer it. -- Lew
From: Patricia Shanahan on 11 Sep 2009 21:46
markspace wrote: > Mike Schilling wrote: > >> Now, when a test calls assertEquals(Boolean, Quaternion), it'll find >> an exact match. > > > I think the OP could just make one assertEquals( Object, Object ) > method, and call the toString of each object. Then compare based on the > strings. > There would be no need to create a new assertEquals. Junit's assertEquals already handles two String arguments. It is a possible solution for the original example, because the toString() of an Integer and a Long are equal if, and only if, they represent the same integer. It is not a general solution, because there is no general guarantee that actual.toString() gives a different result from expected.toString() in all failure cases. In particular, a method that returns Object, String, CharSequence, Serializable, or Comparable could go wrong by returning the toString() of the object it should have returned. A String-base unit test would not distinguish an Object reference to the String "1" from an Object reference to Long.valueOf(1). Patricia |