Thread: Operation ==

Hi,

I wrote the following code:

Ingeter i1 = 10;
Ingeter i2 = 10;
if (i1 == i2)
    Stystem.out.println(" == Integer");
Double d1 = 10.0;
Double d2 = 10.0;
if (d1 == d2)
    Stystem.out.println(" == Double");

The output is:
== Integer

Question:
I'm trying to understand why in one case (Integer, Boolean, String etc) the operation == is true and in oher case (Double,Float etc) the operation is false?

Thanks.

Low-down, object variables hold an address that points to the location of the object. Using the == operator on any such variables will try to compare the addresses of the two objects rather than comparing the objects themselves. Obviously, if both objects point to the same object == will return true. However, if they point to different objects there is no way to tell if the objects are equal, only that they are not the same object. Instead, there is an equals method that actually compares the contents of objects according to the way the method is defined.

The reason primitive values can be compared using the == operator is they don't contain an address to an object, but rather contain the value directly.

Integer a = new Integer(5);
Integer b = new Integer(5);
if(a == b)
{
     System.out.println("This code won't get executed because they point to different objects");
}
if (a.equals(b))
{
     System.out.println("This code will get executed because their contents are the same");

helloworlds response is much more eloquent than mine

Originally Posted by meytalg

Thanks for the answer.

Is there any way to know which object returns true when I'm using the operation == (without test it)?
(this question was part of my job interview and I could not test it)

Thanks.

Basically, if you ever assign an object to another using '=' instead of new, the == will evaluate to true for both assignees. In this particular case with the Integer object, one may think i1 and i2 are NOT equal based upon this assumption:
s

Integer i1 = 10;
Integer i2 = 10;
if (i1 == i2)//will return true

but you need to dig deep to know why. In the manner in which you assigned the values of i1 and i2 (i1 = 10), you let the compiler do it for you (as opposed to using new Integer(10) explicitely). To do the asignment, the compiler uses the static function Integer.valueOf(10) to get the Integer of value 10 for you. However, the Integer object has a cache of static Integer objects for the values -128 to 127 and returns one of these if it be within this range. Therefore in this case of 10, it retrieves the cached object of value 10. After all is said and done, each Integer you end up with refers to the same object/address/memory space: they are equal both in value and in memory space: == will return true.
Try the same and instead of 10, use 128, you will see it will not evaluate to true.

Integer i1 = 10;//assigns i1 to a cached static Integer
Integer i2 = 10;//assigns i1 to a cached static Integer (the same as above)
if (i1 == i2)//will return true
 
Integer i1 = 128;//no cached Integer, returns a new Object
Integer i2 = 128;//no cached Integer, returns a new Object
if (i1 == i2)//will return false

Certain Strings also get cached. I believe it only caches Strings that are guarenteed constant and static/local.

public static void main(String[] args)
{
	final String c = " world";
	String a = "Hello " + c;
	String b = "Hello world";
	System.out.println(a == b); // will print out true
 
	String d = " world";
	String a = "Hello " + d;
	System.out.println(a == b); // will print out false
}

Originally Posted by helloworld922

Certain Strings also get cached. I believe it only caches Strings that are guarenteed constant and static/local.]

The compiler does a pretty darn good job of re-using Strings from memory, say for example within functions and objects (not to the extent that I'd trust == though). You can also 'force caching' using the intern() function of String, although I've never found the need to do this.