Integer / Long comparison
in [Java Help]
|
Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME
From: markspace on 12 Sep 2009 00:22 Patricia Shanahan wrote: > > There would be no need to create a new assertEquals. Junit's > assertEquals already handles two String arguments. I was trying to be facetious. Declare an argument type of Object, and with auto-boxing one loses all control of type. "Object" will literally accept any type of argument at all. Type troubles will go away, but like weakly typed languages like PHP, you might find other troubles surface later. > 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. Like this one. ;)
From: Pitch on 12 Sep 2009 05:09 In article <8a4c111a-63ae-4ede-adb4-6008cc99a207 @j4g2000yqa.googlegroups.com>, lew(a)lewscanon.com says... > 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. I thought he was talking about micro-optimizations and avoiding two conversions. -- stirr your cofee properly
From: Lew on 12 Sep 2009 12:05 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. Lew wrote: >> There isn't a performance issue here in the first place. Pitch wrote: > I thought he was talking about micro-optimizations and avoiding two > conversions. There weren't two conversions, only one. The one is a widening from int to long, hardly expensive enough to constitute a performance issue. All Hotpost would have to do is load the int into a 64=bit register and the conversion is essentially free. There isn't a performance issue here in the first place. -- Lew
From: Patricia Shanahan on 12 Sep 2009 13:02 markspace wrote: > Patricia Shanahan wrote: >> >> There would be no need to create a new assertEquals. Junit's >> assertEquals already handles two String arguments. > > > I was trying to be facetious. ... Sorry - my facetiousness meter seems to be broken this week. Patricia
From: Mike Schilling on 12 Sep 2009 14:47
Lew wrote: > 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. > > Lew wrote: >>> There isn't a performance issue here in the first place. > > Pitch wrote: >> I thought he was talking about micro-optimizations and avoiding two >> conversions. > > There weren't two conversions, only one. The one is a widening from > int to long, hardly expensive enough to constitute a performance > issue. All Hotpost would have to do is load the int into a 64=bit > register and the conversion is essentially free. There isn't a > performance issue here in the first place. These are unit tests, and the assertEquals call is to verify the correctness of some presmably non-trivial operation. There wouldn't be a performance issue even if there were 12 conversions. |