6

I have been told to never use == for strings but for everything else because .equals would compare the values rather than the instances of the object. (Which I understand the difference of).

According to some sites, == compares memory locations?

What I don't understand is if you're comparing an integer with another, why would it compare memory locations, or is this just for strings?

If you're comparing int 3 to int 4 obviously it wouldn't be in the same memory location, but then if you're comparing int 4 to int 4, does that mean all integers with the value of 4 is stored in the same memory location?

aioobe
  • 413,195
  • 112
  • 811
  • 826
liloka
  • 1,016
  • 4
  • 14
  • 29

9 Answers9

12

According to some sites, == compares memory locations?

The expression a == b compares the content of a and b, regardless of their types.

What I don't understand is if you're comparing an integer with another, why would it compare memory locations, or is this just for strings?

In case a and b are references, the == operator will compare "memory locations" since that is what the variables contain.

In case a and b are of primitive types, such as int or double the variables will contain actual values, consequently these values (and not their locations) will be compared.

(Note that a variable can never contain an object such as a String, it can at most point at an object.)

Does that mean all integers with the value of 4 is stored in the same memory location?

No. As explained above, ints are compared "directly". When it comes to Integer the story is slightly different. First of all new guarantees that you get hold of a fresh reference, that is

Object i = new Integer(5);
Object j = new Integer(5);

... i == j ...

will always yield false.

If you go through auto-boxing however:

Object i = (Integer) 5;
Object j = (Integer) 5;

... i == j ...

you'll get true due to the fact that auto-boxing goes through a cache for values in the range -128-127. (See for instance this question: Compare two Integer: why is == true?)

Community
  • 1
  • 1
aioobe
  • 413,195
  • 112
  • 811
  • 826
  • Also if we have 2 strings asigned the same string literal the result of == operation will return true. In this case string vars points to one string literal located in memory(String q = "aa"; String d = "aa"; boolean f = q == d; so f will be true) – maks Nov 11 '11 at 14:37
  • @aioobe, could you please elaborate on that last sentence? – nullpotent Nov 11 '11 at 14:47
  • Updated answer. What I'm trying to say is that when an `int` is auto-boxed to a (reference to an) `Integer`, the JVM checks if the value is small. If it is, it returns a reference to an existing `Integer`-object. Thus for small values you'll get the same references for the same values, while as you may get two different references when autoboxing a larger value. – aioobe Nov 11 '11 at 14:52
  • All good but it might be good to mention that every call to `Integer.valueOf(5)` *will* return the same `Integer` reference more low integer values depending on the JVM object cache configs. It is recommended that folks use `valueOf` instead of allowing autoboxing or `new Integer(X)`. – Gray Nov 22 '11 at 21:36
4

== compares the values of the oparands whether it is primitive or reference type.

  1. If the operands are primitive the values of the operands will be compared.

  2. Operands which are references contains values i.e. address to access the object they are referring to. String are not primitive data type, they are considered as objects in java, When you are comparing two references of type string, the result will be true only when the values of the operands i.e. address of the String objects are equal ( which means they refer to the same String object).

Keen Sage
  • 1,899
  • 5
  • 26
  • 44
2

Simply put: the thing is that int is a primitive type whereas String is an object. The values of primitive types can be compared with == since the variable points to the value itself rather than the reference to the value.

Marcus
  • 12,296
  • 5
  • 48
  • 66
1

int's are primitive types in java and as such they don't represent an object "reference" but the value directly.

OscarRyz
  • 196,001
  • 113
  • 385
  • 569
1

== compares reference types. int is a primitive type.

so:

int x = 3;
int y = 3;

x==y is true

but using the Integer reference type

Integer x = new Integer(3);
Integer y = new Integer(3);

x == y is false
JHolyhead
  • 984
  • 4
  • 8
1

The == operator compares the references of objects in memory and Strings are objects - primitives aren't objects so as long as they are of the same type, then == will work. As you say, if they are the object variants of primitives (e.g. Integer for int) then java (>5) autoboxes in order to do the compare.

purelylogical
  • 176
  • 3
1

From the Java Specification 15.21 Equality Operators:

15.21 Equality Operators

The equality operators are syntactically left-associative (they group left-to-right), but this fact is essentially never useful; for example, a==b==c parses as (a==b)==c. The result type of a==b is always boolean, and c must therefore be of type boolean or a compile-time error occurs. Thus, a==b==c does not test to see whether a, b, and c are all equal.

EqualityExpression: RelationalExpression EqualityExpression == RelationalExpression EqualityExpression != RelationalExpression The == (equal to) and the!= (not equal to) operators are analogous to the relational operators except for their lower precedence. Thus, a

In all cases, a!=b produces the same result as !(a==b). The equality operators are commutative if the operand expressions have no side effects.

15.21.1 Numerical Equality Operators == and !=

If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (§5.1.8) to numeric type, binary numeric promotion is performed on the operands (§5.6.2). If the promoted type of the operands is int or long, then an integer equality test is performed; if the promoted type is float or double, then a floating-point equality test is performed. Note that binary numeric promotion performs value set conversion (§5.1.13) and unboxing conversion (§5.1.8). Comparison is carried out accurately on floating-point values, no matter what value sets their representing values were drawn from.

Floating-point equality testing is performed in accordance with the rules of the IEEE 754 standard:

If either operand is NaN, then the result of == is false but the result of != is true. Indeed, the test x!=x is true if and only if the value of x is NaN. (The methods Float.isNaN and Double.isNaN may also be used to test whether a value is NaN.) Positive zero and negative zero are considered equal. Therefore, -0.0==0.0 is true, for example. Otherwise, two distinct floating-point values are considered unequal by the equality operators. In particular, there is one value representing positive infinity and one value representing negative infinity; each compares equal only to itself, and each compares unequal to all other values. Subject to these considerations for floating-point numbers, the following rules then hold for integer operands or for floating-point operands other than NaN: The value produced by the == operator is true if the value of the left-hand operand is equal to the value of the right-hand operand; otherwise, the result is false. The value produced by the != operator is true if the value of the left-hand operand is not equal to the value of the right-hand operand; otherwise, the result is false. 15.21.2 Boolean Equality Operators == and !=

If the operands of an equality operator are both of type boolean, or if one operand is of type boolean and the other is of type Boolean, then the operation is boolean equality. The boolean equality operators are associative. If one of the operands is of type Boolean it is subjected to unboxing conversion (§5.1.8).

The result of == is true if the operands (after any required unboxing conversion) are both true or both false; otherwise, the result is false.

The result of != is false if the operands are both true or both false; otherwise, the result is true. Thus != behaves the same as ^ (§15.22.2) when applied to boolean operands.

15.21.3 Reference Equality Operators == and !=

If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality. A compile-time error occurs if it is impossible to convert the type of either operand to the type of the other by a casting conversion (§5.5). The run-time values of the two operands would necessarily be unequal.

At run time, the result of == is true if the operand values are both null or both refer to the same object or array; otherwise, the result is false.

The result of != is false if the operand values are both null or both refer to the same object or array; otherwise, the result is true.

While == may be used to compare references of type String, such an equality test determines whether or not the two operands refer to the same String object. The result is false if the operands are distinct String objects, even if they contain the same sequence of characters. The contents of two strings s and t can be tested for equality by the method invocation s.equals(t). See also §3.10.5.

reevesy
  • 3,452
  • 1
  • 26
  • 23
Ernesto Campohermoso
  • 7,213
  • 1
  • 40
  • 51
0

Objects are equality by value, but the value that objects have is a reference to the memory location. Primitives (i.e. int, boolean, char, double) do not use references, but store their value. So when == is used, it compares the value of the two. In the case of objects it's a reference; however, in the case of primitives it is the value it stores.

Jordan Blanco
  • 1
  • Additional note: Classes like `Integer` represent `Object`s, so there's a huge difference between `==` being used for e.g. `int` and `Integer`. – class stacker Mar 05 '13 at 14:45
0

The == operator compares ints by value and objects by address. Thus, == is correct for ints but (usually) not for Strings.

Note that if you know that both Strings have been returned by the String.intern method, == works correctly, as intern is guaranteed to return the same address for identical strings.

ibid
  • 3,891
  • 22
  • 17