O código abaixo está imprimindo int e Integer são iguais.
Integerinteger_n=2;//autoboxing.intm=2;System.out.println(m==integer_n?"int e Integer são Iguais":"int e Integer são Diferentes");
Quando utilizo o operador == com objetos, estou comparando o endereço de memória. Se os objetos comparados estiverem apontando para o mesmo endereço de memória, então será retornado true. Só que no meu caso, estou comparando um int com um objeto Integer. Estou comparando o valor 2 com o endereço de memória que se encontra integer_n, não estou correto?
Para mim, essa comparação deveria retornar false. Por acaso, quando realizo a comparação, é realizado um autoboxing do m para Integer, ou unboxing do integer_n para int? É a única saída que vejo para que essa comparação retorne true.
Além disso, lembre-se que os wrappers tem um cache e números no intervalo de um byte (-128 até 127) são sempre convertidos para a mesma instância.
ECO2004
Obrigado, Viny.
Há um pool para Integer (e também para Short) e um pool para String, mas não há pool para Double, nem para Float.
Por que há para inteiros e não para fracionários?
Outra dúvida: o Java faz uma conversão implícita de tipos quando não há perda de valores, como:
doublen;intm=2;n=m;//funciona perfeitamente
Doublen=2;//gera erro.
Para mim, a JVM faria uma conversão implícita, depois um autoboxing, mas isso não ocorre. Sabe o porquê?
ViniGodoy
O certo é:
Doublen=2.0;
Quantos números deveria haver num pool float? Lembre-se que num double que existem “infinitos” números entre 0 e 1 (0.1, 0.01, 0.001, 0.2, e assim por diante).
A
AbelBueno
A título de curiosidade (provavelmente inútil) o limite superior do pool de inteiros pode ser definido pela linha de comando, setando a propriedade java.lang.Integer.IntegerCache.high (pelo menos para a VM da Oracle).
Isso pode gerar efeitos estranhos se você utilizar o operador == para comparar Integers.
