Почему сравнение Integer с int может вызвать исключение NullPointerException в Java?

Мне было очень непонятно наблюдать за этой ситуацией:

Integer i = null;
String str = null;

if (i == null) {   //Nothing happens
   ...                  
}
if (str == null) { //Nothing happens

}

if (i == 0) {  //NullPointerException
   ...
}
if (str == "0") { //Nothing happens
   ...
}

Итак, поскольку я думаю, что сначала выполняется операция бокса (т.е. java пытается извлечь значение int из null), а операция сравнения имеет более низкий приоритет, поэтому возникает исключение.

Возникает вопрос: а почему в Java это реализовано именно так? Почему бокс имеет больший приоритет, чем сравнение референсов? Или почему не внедрили проверку против nullдо бокса?

На данный момент это выглядит несовместимым, когда NullPointerExceptionвыбрасывается с обернутыми примитивами и не генерируется с истинными типами объектов.

Краткий ответ

Ключевой момент заключается в следующем:

• == между двумя ссылочными типами всегда выполняется сравнение ссылок
  • Чаще всего, например, с Integerи String, вы хотите использовать equalsвместо
• == между ссылочным типом и числовым примитивным типом всегда числовое сравнение
  • Тип ссылки будет подвергнут преобразованию распаковки
  • Распаковка nullвсегда выкидываетNullPointerException
• Хотя в Java есть много специальных методов String, на самом деле это НЕ примитивный тип.

Приведенные выше утверждения справедливы для любого допустимого кода Java. С таким пониманием в представленном вами фрагменте нет никаких противоречий.

Длинный ответ

Вот соответствующие разделы JLS:

JLS 15.21.3 Операторы эталонного равенства ==и!=

Если операнды оператора равенства имеют либо ссылочный тип, либо нулевой тип, тогда операция является равенством объектов.

Это объясняет следующее:

Integer i = null;
String str = null;

if (i == null) {   // Nothing happens
}
if (str == null) { // Nothing happens
}
if (str == "0") {  // Nothing happens
}

Оба операнда являются ссылочными типами, поэтому == сравнивается равенство ссылок.

Это также объясняет следующее:

System.out.println(new Integer(0) == new Integer(0)); // "false"
System.out.println("X" == "x".toUpperCase()); // "false"

Чтобы ==быть числовым равенством, по крайней мере один из операндов должен быть числового типа :

JLS 15.21.1 Операторы числового равенства ==и!=

Если оба операнда оператора равенства имеют числовой тип или один имеет числовой тип, а другой может быть преобразован в числовой тип, для операндов выполняется двоичное числовое повышение. Если повышенный тип операндов - intили long, выполняется проверка на равенство целых чисел; если продвигаемый типfloat or double`, то выполняется проверка равенства с плавающей запятой.

Обратите внимание, что двоичное числовое продвижение выполняет преобразование набора значений и преобразование распаковки.

Это объясняет:

Integer i = null;

if (i == 0) {  //NullPointerException
}

Вот выдержка из Effective Java 2nd Edition, пункт 49: Предпочитайте примитивы упакованным примитивам :

Таким образом, используйте примитивы вместо примитивов в штучной упаковке, когда у вас есть выбор. Примитивные типы проще и быстрее. Если вы должны использовать примитивы в штучной упаковке, будьте осторожны! Автобокс снижает многословие, но не снижает опасность использования упакованных примитивов. Когда ваша программа сравнивает два упакованных примитива с ==оператором, она выполняет сравнение идентичности, что почти наверняка не то, что вам нужно. Когда ваша программа выполняет вычисления смешанного типа с использованием упакованных и распакованных примитивов, она выполняет распаковку, а когда ваша программа выполняет распаковку, она может выбросить NullPointerException. Наконец, когда ваша программа упаковывает примитивные значения, это может привести к созданию дорогостоящих и ненужных объектов.

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

Рекомендации

• JLS 4.2. Примитивные типы и значения
  • « Числовые типы - это целые типы и типы с плавающей запятой».
• JLS 5.1.8 Распаковка преобразования
  • «Тип считается конвертируемым в числовой тип, если это числовой тип, или это ссылочный тип, который может быть преобразован в числовой тип путем преобразования распаковки».
  • «Преобразование распаковки преобразует [...] из типа Integerв тип int»
  • «Если rесть null, распаковка преобразование бросает NullPointerException»
• Руководство по языку Java / Autoboxing
• JLS 15.21.1 Операторы числового равенства ==и!=
• JLS 15.21.3 Операторы эталонного равенства ==и!=
• JLS 5.6.2 Продвижение двоичных чисел

Связанные вопросы

• При сравнении двух Integersв Java происходит автоматическая распаковка?
• Почему это, ==а нет equals()?
• Java: в чем разница между автобоксингом и кастингом?

Связанные вопросы

• В чем разница между int и Integer в Java / C #?
• Гарантировано ли, что new Integer (i) == i в Java? (ДА !!! Коробка распакована, а не наоборот!)
• Почему int num = Integer.getInteger("123")бросает NullPointerException? (!!!)
• Java noob: дженерики только для объектов? (Да, к сожалению)
• Java String.equalsпротив==

Ваш пример NPE эквивалентен этому коду благодаря автобоксу :

if ( i.intValue( ) == 0 )

Следовательно, NPE, если iесть null.

if (i == 0) {  //NullPointerException
   ...
}

i - это целое число, а 0 - это целое число, поэтому в действительности делается что-то вроде этого

i.intValue() == 0

И это вызывает nullPointer, потому что i имеет значение null. Для String у нас нет этой операции, поэтому здесь нет исключения.

Создатели Java могли бы определить ==оператор для непосредственного воздействия на операнды разных типов, и в этом случае, учитывая Integer I; int i;сравнение, I==i;можно было бы задать вопрос «Имеет ли Iссылка на объект Integer, значение которого равно i?» - вопрос, на который можно было без труда ответить. даже если Iимеет значение null. К сожалению, Java не проверяет напрямую, равны ли операнды разных типов; вместо этого он проверяет, позволяет ли язык преобразовать тип одного из операндов в тип другого, и, если это так, сравнивает преобразованный операнд с непреобразованным. Такое поведение означает, что для переменных x, yи zс некоторыми комбинациями типов можно иметь x==yи, y==zноx!=z[например, x = 16777216f y = 16777216 z = 16777217]. Это также означает, что сравнение I==iпереводится как «Преобразуйте I в intи, если это не вызовет исключения, сравните его с i».

Это из-за автобокса Javas функции . Компилятор обнаруживает, что в правой части сравнения вы используете примитивное целое число, и ему также необходимо распаковать значение Integer обертки в примитивное значение int.

Поскольку это невозможно (это ноль, как вы обозначили), NullPointerExceptionвыбрасывается.

В i == 0Java попытается выполнить автоматическую распаковку и выполнить численное сравнение (т.е. "- это значение, хранящееся в объекте-оболочке, на которое ссылается iто же, что и на значение0 ?»).

Так как iэто nullраспаковка будет бросатьNullPointerException .

Рассуждения звучат так:

Первое предложение JLS § 15.21.1 Операторы числового равенства == и! = Читается так:

Если оба операнда оператора равенства имеют числовой тип или один имеет числовой тип, а другой может быть преобразован (§5.1.8) в числовой тип, двоичное числовое продвижение выполняется для операндов (§5.6.2).

Очевидно, что он iможет быть преобразован в числовой тип и 0является числовым типом, поэтому двоичное числовое продвижение выполняется для операндов.

В § 5.6.2 Рекламное продвижение двоичных чисел (среди прочего) говорится:

Если какой-либо из операндов имеет ссылочный тип, выполняется преобразование распаковки (§5.1.8).

§ 5.1.8 Преобразование распаковки говорит (среди прочего):

Если r равно нулю, преобразование распаковки вызываетNullPointerException

Просто напишите метод и вызовите его, чтобы избежать исключения NullPointerException.

public static Integer getNotNullIntValue(Integer value)
{
    if(value!=null)
    {
        return value;
    }
    return 0;
}