pra mim a saída seria false e false.
Pois quando entra no method a variavel primitiva int passa por boxing e se Transforma em um Integer, e como no == ele compara a referência desses Objetos avaliei como False, mas a saída foi true e false.
Qual a explicação pra isso?
existe uma regra, lí em algum topico q numero acima de 127 tem uma regra.... e se tem... tenho que me preocupar com questões assim na prova de certificação?
A respeito do código, o compilador java sabe que na hora de comparar os objetos do tipo java.lang.Integer, na verdade ele tem que comprar o valor numérico e não as referencias.
Mas esse lance do 127 eu não to sabendo não… vou dar uma pesquisada.
sergiolopes
Algumas implementacoes da classe Integer (a da Sun, por exemplo) fazem um cache de objetos para valores “pequenos” de Integers. O auto-boxing quando executado na verdade faz uma chamada a Integer.valueOf(int) que usa esse cache. Na VM da Sun o cache vai de -128 a 127.
Olha o código fonte da classe Integer da Sun. Veja na linha 601 o método valueOf e a chamada do cache. Aliás na linha 578 voce encontra a classe interna IntegerCache que faz justo isso.
Mas duvido que na SCJP caia esse tipo de coisa até porque isso é detalhe de implementação (nem o javadoc fala disso). E lembre que comparação de Integer deve ser feita com equals sempre, já que são objetos. Se fizer assim, nunca terá problemas.
[]'s
moacirjava
Essa regra é válida somente para ints ou outros tipos tem uma limitação igual?
E
enantiomero
Tanto é que é apenas um detalhe de implementação, que na versão 7 do JDK será possível passar um daqueles famosos parâmetros -XX alguma coisa para poder ajustar o tamanho desse cache. (Não me lembro mais em que build isso foi acrescentado). Portanto não faz sentido você decorar que o tal cache vai de -128 até +127 (no caso dos tipos int, short, long, byte) ou de (char) 0 a (char) 127 (no caso do tipo char). Não faz sentido algum.
