2013-12-21 4 views
1

Код:.equals() и == в Java на Integer (== работал, но .equals не !!)

call.getUserId().equals(ITConstants.SPECIALID) 

public static final Integer SPECIALID= 0; 

POJO:

public class ImCall implements java.io.Serializable { 
private Integer userId; 

HBM:

<property name="userId"> 
    <column name="USER_ID" /> 
</property> 

MySQL:

int(11) is the datatype in MySQL 

Когда UserId был равен нулю. .Equals() "не работал (возвращается false), но на удивление работает" == "(возвращается true). Я думал, что это из-за некоторых проблем в Tomcat Server.Также я очистил его и перезапустил. Эта же проблема.

Но снова через пару дней проблема, о которой я упоминал выше, не повторилась. Но теперь оба == и .equals() работают!

Итак, мой первый вопрос: существует ли ситуация, когда «==» работает, а «.equals()» - нет. Второй вопрос: почему «==» возвращает true в этом случае?

Редактировать:

Getters return Integer only.

public Integer getUserId() { 
    return userId; 
} 

public void setUserId(Integer userId) { 
    this.userId = userId; 
} 
+0

Покажите, каковы ваши значения и каков ожидаемый результат. Я, например, не уверен на 100%, что 'call.getUserId()' возвращает 'Integer', он * может * возвращать' int'. – skiwi

+0

@skiwi Getters возвращает целое число.Пожалуйста, см. Мое редактирование – user104309

ответ

2

Я уверен, что в вашем тесте должно быть что-то не так. Симптомы, которые вы описываете, никогда не должны происходить.

Единственный способ для == не быть equals() - если была плохая реализация вашего метода equals. В случае Integer, который является основным классом Java, этого просто не произойдет.

Однако то, что могло бы произойти, если тип данных вернулся в другой формат (Float или Long, например), чем вы ожидали, что equals() может потерпеть неудачу там.

Например, 3 == 3L возвращает true, но new Integer(3).equals(new Long(3)) возвращает false. Это связано с тем, что case == с примитивами позволяет продвигать целое число дольше, чтобы выполнить сравнение.

Попробуйте сами здесь: http://www.tryjava8.com/app/snippets/52b5878ce4b0f5090255bc17

+0

Спасибо Тиму за ответ на мой первый вопрос и за ссылку. – user104309

+0

Держитесь, однако, это не то, что происходит, не так ли? 'getUserId()' возвращает Integer, а 'ITConstants.SPECIALID' также является Integer. Кроме того, если '==' работал, то это означает, что они были одним и тем же экземпляром Integer, и поэтому '.equals()' должно было работать ... правильно? – Erhannis

+0

@ Erhannis Правильно. В моем первом предложении говорилось, что в его тесте должно быть что-то не так, поскольку результаты, которые он дал, в принципе невозможны. Однако я тогда объяснил проблему, которая дает очень похожие (но возможные) симптомы, и похоже, что это была проблема. –

2

Tim B ответил на первый вопрос. Я просто хочу добавить ответ для второго.

В Java по умолчанию используется кеш для целых чисел от -128 до 127.

Таким образом, даже если вы работаете с объектом (в штучной упаковке), представление функции int, == будет работать правильно, потому что вместо объекта будет использоваться кешированное значение.

+1

True для Integer.valueOf. Также верно для автоматического бокса. Не верно для нового Integer. –

+0

Хорошо, может быть, я должен быть более общим. Но в этом конкретном случае Hibernate значения кэшируются. –

+0

Спасибо Максиму за ответ на мой второй вопрос и введение в кеширование Integer. – user104309