How to ensure == will always work with primitives as an equality test

Question

From what I understand, if I have two long or int, the == operator to test equality of values will not work sometimes due to autoboxing.

What do I need to do to ensure that == will work in every possible scenario when dealing with primitives?

AIUI, comparing `double` values with `==` is rarely a good idea. — Duncan Jones, Oct 30 '13 at 15:23
http://www.javapractices.com/topic/TopicAction.do?Id=197 has some info — Tim S., Oct 30 '13 at 15:23
Can you provide a code sample the triggers the problem you are describing? — Duncan Jones, Oct 30 '13 at 15:24
I read it on an answer here: http://stackoverflow.com/questions/1586223/how-does-the-tostring-equals-object-methods-work-differently-or-similar — user2763361, Oct 30 '13 at 15:24
For floating point data types, `abs(d1 - d2) < someDegreeOfAccuracy` is a better idea. — nhgrif, Oct 30 '13 at 15:26

Peter Lawrey · Accepted Answer · 2013-10-30T21:07:44.847

7

Backward compatibility demands (and the JLS agrees) that if you had an expression like

double a = ..
double b = ...
if (a == b) // condition

This condition must work the same way it did before auto-boxing as after autoboxing. This means autoboxing cannot and must not apply here.

In fact autoboxing is never used to compile an == expression if it can use unboxing instead.

Integer i = 1000;
int j = 1000;
System.out.println(i == j); // is true

In this case unboxing is chosen over boxing.

edited Oct 30 '13 at 21:07

answered Oct 30 '13 at 15:28

Peter Lawrey

525,659
79
751
1,130

1

The statement `autoboxing is never used to compile an == expression` is not quite true. If `a` is declared as `Object` and `b` is declared as `int`, `a==b` will autobox `b` to an `Integer`. – ajb Oct 30 '13 at 20:29

score 2 · Answer 2 · edited Jun 20 '20 at 09:12

The JLS (§15.21.1) says:

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).

Note that binary numeric promotion performs value set conversion (§5.1.13) and may perform unboxing conversion (§5.1.8).

So the problem you describe occurs only if both operands are boxed types (Double, Integer, etc.). Whether the operand type is boxed or not depends on how the operand is declared. If it's a variable, field or parameter, it depends on the type used to declare the name; if it's a method call, it depends on the return type used when the method is declared; if it's the result of some other operation like +, it should already be unboxed; if a typecast has been applied, the cast will tell you what the type is.

As others have said, you usually shouldn't use == to compare doubles or floats due to rounding errors.

Voidpaw · Answer 3 · 2013-10-30T15:32:37.413

0

Fafaik you can not get boxing with two primitives. Boxing occurs when you were to take (for example) and int and an Integer, or a double and a Double. Unboxing get the primitive from the "box" (the Object equivalent) to then compare the two primitives with the == operator, in which case there is no guarantee they are the same. If you have two doubles however you will not have this problem.

edited Oct 30 '13 at 15:32

answered Oct 30 '13 at 15:27

Voidpaw

910
1
5
18

No, this is wrong. If you compare a `double` and a `Double`, it will unbox the `Double`, not box the `double`. – ajb Oct 30 '13 at 15:30
2

I am sorry, you are completely correct - I will change this straight away. – Voidpaw Oct 30 '13 at 15:31

How to ensure == will always work with primitives as an equality test

3 Answers3