26
Integer valor = 127;
Integer valor2 = 127;
System.out.printIn(valor == valor2);
Output: true
Integer valor = 128;
Integer valor2 = 128;
System.out.printIn(valor == valor2);
Output: false
Why does that happen?
26
Integer valor = 127;
Integer valor2 = 127;
System.out.printIn(valor == valor2);
Output: true
Integer valor = 128;
Integer valor2 = 128;
System.out.printIn(valor == valor2);
Output: false
Why does that happen?
26
Integer class is part of the class package Wrapper and not of a primitive type of data, such as int
. What we call Wrapper is a class that represents a primitive type. For example the Wrapper of int
is the Integer
. Realize that the Wrapper starts with uppercase letter, it follows the same nomenclature as any other class, as it is also a.
For this reason the operator ==
is not recommended to compare class values Integer
. For this we use another comparator, the equals
.
Example 1:
Integer valor = 127;
Integer valor2 = 127;
System.out.println(valor == valor2); // Saída: true
System.out.println(Objects.equals(valor, valor2)); // Saída: true
Notice that in both cases it returns true.
Now let’s look at another example:
Integer valor3 = 128;
Integer valor4 = 128;
System.out.println(valor3 == valor4); // Saída: false
System.out.println(Objects.equals(valor3, valor4)); // Saída: true
But the question is, why ==
works for the Integer
127 and not for the Integer
128?
The answer is simple: The JVM is caching entire values. Therefore the ==
works only for numbers between -128 and 127. This cache is mentioned in documentation of the method valueOf
, that, the first impression is called internally when it is made autoboxing, a feature that automatically converts primitive types into its wrapper equivalent.
Observing: If you used the primitive type of data int
a simple comparison using the comparator ==
functionary.
int valorTeste = 128;
int valorTeste2 = 128;
System.out.println(valorTeste == valorTeste2); // Saída: true
It is interesting to note that this cache is mentioned in the documentation of the method valueOf
, that seems to be the method called internally when doing autoboxing
Exactly @hkotsubo, well remembered.
15
Integer valor = 127;
creates an Object of the class Integer
which represents the whole of the
int i = 127;
that only creates a primitive.
The operator ==
serves only to test if it is the same instance, does not compare the content of the instances. Therefore it will normally return false
for two instances of Integer
even if they represent the same value.
The class Integer
has a mechanism to store a certain number of instances (cache) to prevent the creation of new repeated instances. Normally this cache is specified to store integers between -128 and 127 (documentation). The maximum value can be changed through the property java.lang.Integer.IntegerCache.high
. The minimum is fixed at -128
. The compiler uses this method for creating (or converting int
) of Integer
.
So use
Integer valor = 127;
The compiler is translating this into something similar to
Integer valor = Integer.valueOf(127);
and ends up using the instance stored in the cache, also to
Integer valor2 = 127;
and the result of valor == valor2
will be true
because it is the same body.
If for example you do
Integer valor2 = new Integer(127);
will be creating a new instance and the result of valor == valor2
will be false
.
Obs: similar happens in class String
where the constant values are internalised, see method Intern(). Example: new String("abc") != "abc"
9
First it is important to understand that Integer
is a class in java
, while int
is a primitive type.
This way, when using Integer valor
is creating an object. This serves, for example, to make operations that a primitive type cannot do, such as containing nulls or serving as a key to an object HashMap
, which requires an object as a key.
Thus, his comparison was made using int
, would return true
:
int valor-18;
int valor2 = 128;
System.out.println(valor == valor2);
Why the difference with Integer, with 127 returning true?
Reading this response from the OS: https://stackoverflow.com/a/1700109/4730201
The java documentation is shown: http://java.sun.com, quoting, in free translation:
If p being value Boxed is true, false, one byte, one character in range u0000 to u007f or an int or a short number between -128 and 127, then makes R1 and R2 the results of any two conversions of Boxing p. This is always the case that R1 == R2
Remembering that Boxing is the conversion process of a value type (value type) for an object of a class, or for the interface type of a class, for example, convert a primitive type int for a class Integer.
In short, the problem with the difference in 128 values is that up to 127, java does this Boxing, resulting in two equal objects, and the value 128 or more behaves differently, generating two objects not necessarily equal.
If the Boxing is not automatic, even with the value 127 will result in different objects, so test:
Integer valor = new Integer(127);
Integer valor2 = new Integer(127);
Like Integer
generates an object, if you do so, return true:
Integer valor = new Integer(128);
Integer valor2 = valor;
I rode a fiddle with these tests: jdoodle.com/a/DAM
Browser other questions tagged java
You are not signed in. Login or sign up in order to post.
I believe it has to do with some autoboxing that this class performs internally. I can guess that, by being 127, it makes autoboxing to byte, which justifies the result of the first true return. Already on Monday, it seems that it does not occur
==
– user28595