Comparison with operator ==, how does it work?

Question

I came up with the following question in a Java test:

import java.awt.Button;
class CompareReference 
{
    public static void main(String [] args) 
    {
        float f = 42.0f;
        float [] f1 = new float[2];
        float [] f2 = new float[2];
        float [] f3 = f1;
        long x = 42;
        f1[0] = 42.0f;
    }
}

which three statements are true?

f1 == f2
f1 == f3
f2 == f1[1]
x == f1[0]
f == f1[0]

I need to choose only 3 statements.

Well, 1 is obviously false because we'were comparing two different references, 2 is obviously true because the references are the same. But I don't know about primitives. What I'm confused by is that if we compare Integers in range -128 to 127 they are caching. Related topic. Is there something about primitives, some narrow cases?

I was looking for how it works in the JLS 8 but didn't find anything useful.

that is when it autobox, there is no autoboxing here, it is just plain primitive value comparission — jmj, Dec 31 '14 at 08:19
indeed. also you could just run a program that outputs the true/false value of the above. — Joeblade, Dec 31 '14 at 08:19
*"What I'm confused by is that if we compare Integers in range -128 to 127 they are caching."* Huh? First: There are no `Integer`s in the above. Second: "Caching"?! — T.J. Crowder, Dec 31 '14 at 08:22
@T.J.Crowder Yes, it is. What's wrong? From the JLS: _If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b._ — St.Antario, Dec 31 '14 at 08:24
@St.Antario: There are no boxing conversions anywhere in your code. — NPE, Dec 31 '14 at 08:25
@St.Antario - Yes, `Integer` instances between `-128` to `127` are cached and reused. So, `==` will work on them (because the same instances are reused). The range can be changed as well. Next, as *NPE* points out, your code has no relation with this question. — TheLostMind, Dec 31 '14 at 08:25
@TheLostMind I mean can compariso of floats be tricky? Or we always have that a == b iff they have the same primitive values? — St.Antario, Dec 31 '14 at 08:30
@St.Antario - Yes. Check [this question](http://stackoverflow.com/questions/1088216/whats-wrong-with-using-to-compare-floats-in-java) — TheLostMind, Dec 31 '14 at 08:32

NPE · Accepted Answer · 2014-12-31T08:24:41.450

Comparison 3 will not compile: it tries to compare an array to a scalar.

Comparisons 4 and 5 involve primitives and are done by value. There are no references or autoboxing involved. Therefore the following is not relevant here:

What I'm confused by is that if we compare Integers in range -128 to 127 they are caching.

Since 42 can be represented exactly as a float, comparison 4 will return true.

Comparison 5 will also return true since it's comparing two identical float values.

score 1 · Answer 2 · answered Dec 31 '14 at 08:25

1

2, 4 and 5 are true.

Although remember that comparing floats by == might be tricky, it's safer to do this like this:

Math.abs(float1 - float2) < epsilon

where epsilon is some small number (precision).

answered Dec 31 '14 at 08:25

bartektartanus

15,284
6
74
102

Comparison with operator ==, how does it work?

2 Answers2