Integer / Long comparison

[grz01]

Hi
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

Now, if I try this instead:

Integer i = ...;
Long l = ...;
assertEquals(i,l.intValue);

assertEquals() still complains it doesnt know whether I mean
assertEquals(int, int) or
assertEquals(Integer, Integer)

Thus, if I write

Integer i = ...;
Long l = ...;
assertEquals(i,(Integer)l.intValue);

it does what I want, but seems a bit verbose with two "casts".

So just wondered, Is there a direct way to go from Long to Integer,
without the intermediate int-step ?

/ grz01

 

[Daniel Pitts]

Hi
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

This will always fail anyway, because they are different classes.

Now, if I try this instead:

Integer i = ...;
Long l = ...;
assertEquals(i,l.intValue);

there is no such field called intValue.

assertEquals() still complains it doesnt know whether I mean
assertEquals(int, int) or
assertEquals(Integer, Integer)

Assuming you mean't intValue() above.

Thus, if I write

Integer i = ...;
Long l = ...;
assertEquals(i,(Integer)l.intValue);

it does what I want, but seems a bit verbose with two "casts".

intValue() isn't a cast. Either way, you're better off casting the i to
a long (because there are longs that can't be represented as an integer,
and your equals case might miss that)

So just wondered, Is there a direct way to go from Long to Integer,
without the intermediate int-step ?

If possible, use int and long to start with, rather than Integer and Long.

Then you can do
assertEquals((long)i, l);

 

[Lew]

This will always fail anyway, because they are different classes.



there is no such field called intValue.


Assuming you mean't intValue() above.




intValue() isn't a cast.  Either way, you're better off casting the i to
a long (because there are longs that can't be represented as an integer,
and your equals case might miss that)


If possible, use int and long to start with, rather than Integer and Long..

Then you can do
assertEquals((long)i, l);

or

assertEquals( i.longValue(), l.longValue() );


Why make things complicated?

 

[grz01]

Hi Daniel,

Yes, of course, I meant the intValue() method.

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.

In my code it's actually something like

assertEquals(good.grief(), (Integer)oh.dear().intValue())

which doesnt look very nice...

So, I am still interested if somebody can rewrite that line of code in
a nicer way, without the casting/conversion in two separate steps.

Instead of: Long -> int -> Integer,
I was hoping you could do it in one direct step: Long -> Integer.

Anyone?

/ grz01

 

[grz01]

  assertEquals( i.longValue(), l.longValue() );

Why make things complicated?

Thanks Lew, but still 2 different conversions in the code

I would like only one, if possible

 

[Lew]

So, I am still interested if somebody can rewrite that line of code in
a nicer way, without the casting/conversion in two separate steps.

Instead of:  Long -> int -> Integer,
I was hoping you could do it in one direct step: Long -> Integer.

Sometimes when working with classes like Long and Integer, a visit to
their respective Javadocs might find methods in both that could make
them commensurate, like, oh, say, longValue().

The Javadocs are a very potent resource.

 

[Lew]

Thanks Lew, but still 2 different conversions in the code

I would like only one, if possible

???

What do you imagine the difficulty to be with the two "conversions"
that you imagine happening here?

 

[grz01]

What do you imagine the difficulty to be with the two "conversions"

that you imagine happening here?

Hi Lew,

Just like with

assertEquals(good.grief(), (Integer)oh.dear().intValue())

it's not a "difficulty", admittedly. That works, too.
I just think it would be neater with a single step, esp. when this
type of code repeats many hundred times in our test-cases.

But if someone can tell me, with certainty "NO, IT'S NOT POSSIBLE IN
JAVA!"
(to convert Long -> Integer in one step)
then I would be fine with that answer, too
and stop looking...

/ grz01

 

[Lew]

Thanks Lew, but still 2 different conversions in the code

I would like only one, if possible

One of your "conversions" is the call to Long#longValue(), which does
no conversion whatsoever. It extracts the underlying long value of
the Long, something that equals() does anyway, so there's no escaping
it. No additional cost there. The other "conversion" is actually two
operations: the inescapable extraction of the underlying Integer int
value, and the widening conversion to long. So that's two
extractions, one widening conversion and a comparison with my
suggestion.

What you want is to convert, say, an Integer to a Long, not actually
possible, followed by two extractions and a comparison. Even if
conversion of Integer to Long were possible, no doubt it would be more
expensive than the widening of an int to long.

So do you prefer two extractions, an impossible class conversion and a
comparison as you ask, or two extractions, a simple widening primitive
conversion and a comparison, as I suggest?

 

[Lew]

But if someone can tell me, with certainty "NO, IT'S NOT POSSIBLE IN
JAVA!"
(to convert Long -> Integer in one step)
then I would be fine with that answer, too
and stop looking...

The Javadocs tell you that, and that's the most authoritative
"someone" there is for this question.

Read the Javadocs.

The Javadocs are a potent resource.

Don't ignore the Javadocs.

The answer to that question is yes, the conversion of Long to Integer,
which, BTW, is the wrong direction to convert as you've already been
told, as you can tell by reading the Javadocs.

So I suggest that you read the Javadocs.

 

[Lew]

Correction:

The answer to that question is yes, the conversion of Long to Integer,
which, BTW, is the wrong direction to convert as you've already been
told, is impossible,
as you can tell by reading the Javadocs.

 

[Mike Schilling]

Hi Lew,

Just like with

assertEquals(good.grief(), (Integer)oh.dear().intValue())

it's not a "difficulty", admittedly. That works, too.
I just think it would be neater with a single step, esp. when this
type of code repeats many hundred times in our test-cases.

Then write a method

void assertEquals(String s, Long l, Integer i)
{
assertEquals(s, l.longValue(), i.longValue());
}

And call it as often as you like.

 

[Roedy Green]

So just wondered, Is there a direct way to go from Long to Integer,

see http://mindprod.com/applet/converter.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"The coolest thing to do with your data will be thought of by someone else."
~ Rufus Pollock (born: 1978 age: 31) in Talk.

 

[Arne Vajhøj]

Just like with

assertEquals(good.grief(), (Integer)oh.dear().intValue())

it's not a "difficulty", admittedly. That works, too.
I just think it would be neater with a single step, esp. when this
type of code repeats many hundred times in our test-cases.

Let us say that:
- each instance adds 10 nano seconds to your test run
- your test contains 1000 instances
- your test is run 10000 times
then it "cost" you a total of 1/10th of a second.

Not worth it.

Arne

 

[Arne Vajhøj]

Even if the value of a Long is supposed to be in the Integer range, a
unit test should check that it is in range, not assume it.

Very relevant point.

It is not good to check if some code is OK by
assuming that the code is OK.

Arne

 

[Mike Schilling]

Very relevant point.

It is not good to check if some code is OK by
assuming that the code is OK.

I'm also wondering why Longs and Integers insread of longs and ints.
(assertEquals(long, int) would unambiguously call the (long, long)
overload).Without seeing the code it's hard to tell, but I wonder if
it should be using primitives, but autoboxing had made using objects
instead transparent until this cropped up.

 

[Arne Vajhøj]

I'm also wondering why Longs and Integers insread of longs and ints.
(assertEquals(long, int) would unambiguously call the (long, long)
overload).Without seeing the code it's hard to tell, but I wonder if
it should be using primitives, but autoboxing had made using objects
instead transparent until this cropped up.

Maybe they need to be nullable.

But changing them to simple types would absolute help on the problem.

Arne

 

[Joshua Cranmer]

I'm also wondering why Longs and Integers insread of longs and ints.
(assertEquals(long, int) would unambiguously call the (long, long)
overload).Without seeing the code it's hard to tell, but I wonder if
it should be using primitives, but autoboxing had made using objects
instead transparent until this cropped up.

A (Long, Integer) can be passed into a (long, long) method call, so it's
not necessarily the autounboxing per se that's causing the problem.

 

[Mike Schilling]

A (Long, Integer) can be passed into a (long, long) method call, so
it's not necessarily the autounboxing per se that's causing the
problem.

The problem, I suspect, is that assertEquals() has many, many
overloads, and the result is that which one to call is ambiguous .

 

[Mike Schilling]

There is a simple approach to assertEquals that always works,
without
having to spend time rereading the method selection rules in the
JLS.

Decide the appropriate type for the comparison. Cast/box/unbox etc.
to
force both the expect and actual arguments to be expressions of that
type. In the OP's case, I think the appropriate type for the
comparison is long, so I would use the longValue methods to get a
long from each of i and l.

Unless null is a possible and perhaps expected result. Then it's a
bit more complicated.