Java: Integer Equals Vs. ==

Java: Integer equals vs. ==

The JVM is caching Integer values. Hence the comparison with == only works for numbers between -128 and 127.

Refer: #Immutable_Objects_.2F_Wrapper_Class_Caching

Java Compare 2 integers with equals or ==?

int is a primitive. You can use the wrapper Integer like

Integer first_int = 1;
Integer second_int = 1;
if(first_int.equals(second_int)){ // <-- Integer is a wrapper.

or you can compare by value (since it is a primitive type) like

int first_int = 1;
int second_int = 1;
if(first_int == second_int){ // <-- int is a primitive.

JLS-4.1. The Kinds of Types and Values says (in part)

There are two kinds of types in the Java programming language: primitive types (§4.2) and reference types (§4.3). There are, correspondingly, two kinds of data values that can be stored in variables, passed as arguments, returned by methods, and operated on: primitive values (§4.2) and reference values (§4.3).

How == and equal works in java in Case of Integer Object?

Object.hashCode:

The hashCode method defined by class Object does return distinct
integers for distinct objects.

But Integer.hashCode overrides Object.hashCode:

returns a hash code value for this object, equal to the primitive int
value represented by this Integer object.

which means Integers with same hashCode does not have to share the same object.

---

The source code of Integer.hashCode

@Override
public int hashCode() {
    return Integer.hashCode(value);
}

public static int hashCode(int value) {
    return value;
}

---

If you let:

Integer a = 127;
Integer b = 127; 
System.out.println(a.equals(b)); // true
System.out.println(a == b); // true

this is because Integers between [-128, 127] could be cached.

Is it safe to compare two `Integer` values with `==` in Java?

No, it's not the right way to compare the Integer objects. You should use Integer.equals() or Integer.compareTo() method.

By default JVM will cache the Integer values from [-128, 127] range (see java.lang.Integer.IntegerCache.high property) but other values won't be cached:

Integer x = 5000;
Integer y = 5000;
System.out.println(x == y); // false

Unboxing to int or calling Integer.intValue() will create an int primitive that can be safely compared with == operator. However unboxing a null will result in NullPointerException.

LinkedList .equals vs == operator on Integers

Here:

if(currentElm.equals(searchedElem.getObj()))

You are trying to compare currentElm, which is a Node, to searchedElem.getObj(), which is a value inside a Node.

Presumably you mean something like

if (currentElm.getObj().equals(searchElement))

Why does object.equals(new Integer(1)) equate to true?

Integer overrides equals and checks if the underlying int is equal to the int of the other Integer instance, and if so, returns true. The reason why Integer's equals method is invoked, and not the one from Object, is that the runtime type of object is Integer.

Integer is an Object, but due to the overridden equals, no object identity is used.

All following boolean expressions evaluate to true:

    print((new Integer(1).equals(1)));
    print((new Integer(1).equals(new Integer(1))));
    print((((Integer) 1).equals(new Integer(1))));
    print(((Integer) 1).equals(1));

Now consider autoboxing, which reuses instances for values in the range [-128,127]. The following statements about object equality are all evaluating to true:

    1 == ((Integer) 1)
    ((Integer) (-128)) == ((Integer) (-128)) // in autoboxing range
    ((Integer) (+127)) == ((Integer) (+127)) // same

    ((Integer) (-200)) != ((Integer) (-200)) // not autoboxing
    ((Integer) (+200)) != ((Integer) (+200)) // same

    ((Integer) (-128)) != (new Integer(-128)) // explicit new instance, so no autoboxing
    ((Integer) (+127)) != (new Integer(+127)) // same

---

Related Topics