Qual a melhor maneira de se comparar Long e Integer?

15 respostas
P

Fala feras :smiley:

Surgiu uma discussao aqui sobre qual seria a melhor maneira de se comparar Longs e Integer:

Vamos supor que getId() retorne um Long

loginTO.getUsuarioTO().getId().equals(1)
// ou
loginTO.getUsuarioTO().getId().equals(new Long(1))

O mesmo vale se retornasse um Integer.

Abraco

15 Respostas

B

loginTO.getUsuarioTO().getId() == 1

P

E se usasse

loginTO.getUsuarioTO().getId().equals(new Long(N))?

Notei que as vezes, quando era feito loginTO.getUsuarioTO().getId().equals(58), ele dava que era diferente, mesmo se o id fosse 58.

J

equals só se usa para string, o correto é ==

P

Saquei

Valeu!!

rdgms

Olá

Você pode comparar com equals caso seu metodo esteja retornando um objeto:
Como aqui:

Long l = new Long(4); Long l2 = new Long(4); if(l.equals(l2)){ System.out.println("Igual"); }

oO o equals do Object so para String???
Na verdade não. Você pode usar o equals para outras class… você pode criar uma class qualquer
sobreescrever o metodo Equals e criar uma logica para comparar seu objeto.

dm_thiago

Rode o seguinte exemplo:

Integer a = 5000;
Integer b = 5000;
System.out.println(a == b);
		
Integer c = 5;
Integer d = 5;
System.out.println(c == d);

No primeiro sai false, e no segundo sai true. Traduzindo, não use == para comparar objetos quando o objetivo é ver se eles são equivalentes. Para isso voce deve usar equals. == compara se eles tem a mesma referencia, com algumas exceções como pode ser vista no exemplo acima.

J

rdgms:
Olá

Você pode comparar com equals caso seu metodo esteja retornando um objeto:
Como aqui:

Long l = new Long(4); Long l2 = new Long(4); if(l.equals(l2)){ System.out.println("Igual"); }

oO o equals do Object so para String???
Na verdade não. Você pode usar o equals para outras class… você pode criar uma class qualquer
sobreescrever o metodo Equals e criar uma logica para comparar seu objeto


Ok, mas para que criar uma classe para comparar um tipo primitivo?

Vou reformular minha resposta. equals, para comparar objetos, == para tipos primitivos.

rdgms

Ahh sim…
“equals, para comparar objetos, == para tipos primitivos.”

Perfeito eu so fiz a observação para que não entendessem errado mesmo.

ViniGodoy

Pq ele falou explicitamente que está retornando a classe, Long?

Você pode fazer:

usuario.getId().longValue() == 1L;

Ou

usuario.getId().intValue() == 1;

Isso retorna o tipo primitivo, dentro do objeto. É melhor do que promover o primitivo para um objeto e comparar com equals.

rbcunha

Utilize o código abaixo (1), pois ele é protegido contra NullPointerException. Ao contrário do código (2) que irá lançar NullPointerException caso getId() seja nulo.

//1
Long.valueOf(1L).equals(usuario.getId());
//2
usuario.getId().longValue() == 1L;
ViniGodoy

Dessa forma vc também gera um objeto intermediário para um campo como o Id, que não deveria ser Null.

Agora, na verdade, uma comparação dessa tem uma diferença de desempenho tão insignificante nos dois casos, que você deve preferir a que te der menos trabalho para codificar.

rbcunha

Dessa forma vc também gera um objeto intermediário para um campo como o Id, que não deveria ser Null.
Agora, na verdade, uma comparação dessa tem uma diferença de desempenho tão insignificante nos dois casos, que você deve preferir a que te der menos trabalho para codificar.

Como você disse a diferença de desempenho tão insignificante que eu prefiro a primeira forma para todos os casos seja um ID ou não.

Integer.valueOf(1).equals(usuario.getId());

No caso acima nem o objeto intermediário é criado pois ele já existe no cache do Integer.

ViniGodoy

Na prática, vc não vai comprar com uma valor literal. Ao invés de 1L, você usará uma variável, ou seja, usará o cache do Integer se esse valor estiver numa faixa específica. O que, dependendo do banco, pode ser raríssimo. Portanto, haveria geração do objeto intermediário.

De qualquer forma, eu prefiro não ficar “protegendo contra NullPointerException” de maneira implícita. Isso pode mascarar erros, embora também o hábito impeça de gera-los em alguns casos. Mas isso é questão de gosto, e novamente não está associado a performance.

Como já falamos, não tem muita diferença de performance aqui.

Link_pg

Olá!

Sobre a comparação entre equals ou == entre Numbers, se bem me lembro, tem uma curiosidade sobre isso que é o seguinte: se você tentar comparar um Integer (ou Long, whatever) com == que tiver um valor até 127, da true, acima disso, mesmo que o valor seja igual, dará false. Exemplificando:
Integer i1 = 127;
Integer i2 = 127;

System.out.println(i1 == i2); //resultado: true

i1 = 128;
i2 = 128;

System.out.println(i1 == i2); //resultado: false

Talvez por utilizar um pool que seja comum a todos os filhos da classe Number (Byte é o menor, acho). Algo parecido com o pool de Strings.
Denovo: para comparação de objetos, use equals :lol:

Abraços

Natalia_Lima
Link_pg:
Olá! Sobre a comparação entre equals ou == entre Numbers, se bem me lembro, tem uma curiosidade sobre isso que é o seguinte: se você tentar comparar um Integer (ou Long, whatever) com == que tiver um valor até 127, da true, acima disso, mesmo que o valor seja igual, dará false. Exemplificando:
Integer i1 = 127;
Integer i2 = 127;

System.out.println(i1 == i2); //resultado: true

i1 = 128;
i2 = 128;

System.out.println(i1 == i2); //resultado: false

Talvez por utilizar um pool que seja comum a todos os filhos da classe Number (Byte é o menor, acho). Algo parecido com o pool de Strings.
Denovo: para comparação de objetos, use equals :lol:

Abraços

:lol: :lol: :lol: :lol: :lol: :lol:

Meoooo, esse tópico salvou minha pele!
Estava comparando números e o if não estava funcionando mesmo quando eram iguais.
Qse arranquei os cabelos!
rsrs

Poww, valewww mesmo hein..
Curiosidade interessantíssima!

Criado 8 de julho de 2009
Ultima resposta 24 de ago. de 2010
Respostas 15
Participantes 9