views:

409

answers:

6

This sounds like a stupid question, but I'm kinda stuck here.

I have to compare two Integer (not int). How do I compare them?

Integer x = ...
Integer y = ...

I can think of this:

if (x == y)

The == operator only compares references, so this will only work for lower integer values. But perhaps auto-boxing kicks in...?

if (x.equals(y))

This looks like an expensive operation. Are there any hash codes calculated this way?

if (x.intValue() == y.intValue())

A little bit verbose...

EDIT: Thank you for your responses. Although I know what to do now, the facts are distributed on all of the existing answers (even the deleted ones :)) and I don't really know, which one to accept. So I'll accept the best answer, which refers to all three comparison possibilities, or at least the first two.

+16  A: 

Use the equals method. Why are you so worried that it's expensive?

svenningsson
Not in absolute terms, but considering how inexpensive an integer comparison on assembly level is, I thought it can only get much worse.
DR
Don't concern yourself with micro-optimization.
Milan Ramaiya
So what exactly do you thing Integer.equals() does? I put my bet on "a.value==b.value"
ammoQ
@ammoQ: Essentially it does that, but there seems to be an if-clause with instanceof operation, a cast of b to Integer, and call to its intValue() method. So it definitely is more expensive than a primitive integer comparison.
Joonas Pulakka
@Joonas: But that sounds like something the JIT compiler in the JVM would take care of pretty easy anyway?
kigurai
As Reverend Gonzo says, one shouldn't get into micro-optimizations. If, after writing your program, you find that's it's too slow then you profile it. Only then will you know what things to optimize.I've fooled myself so many times thinking I knew where the bottlenecks were in a program only to find that I was completely wrong. Optimize only after profiling peope!
svenningsson
+1  A: 

I would go with x.equals(y) because that's consistent way to check equality for all classes.

As far as performance goes, equals is actually more expensive because it ends up calling intValue().

EDIT: You should avoid autoboxing in most cases. It can get really confusing, especially the author doesn't know what he was doing. You can try this code and you will be surprised by the result;

Integer a = 128;
Integer b = 128;

System.out.println(a==b);
ZZ Coder
+8  A: 
if (x.equals(y))

This looks like an expensive operation. Are there any hash codes calculated this way?

It is not an expensive operation and no hash codes are calculated. Java does not magically calculate hash codes, equals(...) is just a method call, not different from any other method call.

The JVM will most likely even optimize the method call away (inlining the comparison that takes place inside the method), so this call is not much more expensive than using == on two primitive int values.

Note: Don't prematurely apply micro-optimizations; your assumptions like "this must be slow" are most likely wrong or don't matter, because the code isn't a performance bottleneck.

Jesper
equals is a `instanceof` *check*, a `cast` and a call to `intValue()`, before the real `==`. Sure not a reason to do some premature optimization.
Carlos Heuberger
A: 

"equals" is it. To be on the safe side, you should test for null-ness:

x == y || (x != null && x.equals(y))

the x==y tests for null==null, which IMHO should be true.

The code will be inlined by the JIT if it is called often enough, so performance considerations should not matter.

Of course, avoiding "Integer" in favor of plain "int" is the best way, if you can.

[Added]

Also, the null-check is needed to guarantee that the equality test is symmetric -- x.equals(y) should by the same as y.equals(x), but isn't if one of them is null.

mfx
It's almost always better to just let a NullPointerException throw if a reference is null.
Kevin Bourrillion
But you surely would not use "Integer" instead of "int" if there was was no valid situation where the value is null?
mfx
+3  A: 

This is what the equals method does:

public boolean equals(Object obj) {
    if (obj instanceof Integer) {
        return value == ((Integer)obj).intValue();
    }
    return false;
}

As you can see, there's no hash code calculation, but there are a few other operations taking place there. Although x.intValue() == y.intValue() might be slightly faster, you're getting into micro-optimization territory there. Plus the compiler might optimize the equals() call anyway, though I don't know that for certain.

I generally would use the primitive int, but if I had to use Integer, I would stick with equals().

Jeff
A: 

The Integer class implements Comparable<Integer>, so you could try,

x.compareTo(y) == 0

also, if rather than equality, you are looking to compare these integers, then,

x.compareTo(y) < 0 will tell you if x is less than y.

x.compareTo(y) > 0 will tell you if x is greater than y.

Of course, it would be wise, in these examples, to ensure that x is non-null before making these calls.

jhumble