Какие проблемы могут возникнуть при приведении типов long и Integer в Java

Что проверяют

Понимаете ли вы разницу между примитивами и обёртками и правила автоупаковки, а не только то, что long шире int. Следом нередко показывают код с Map<Long, ...> и спрашивают, почему get возвращает null.

Как отвечать

Разделите проблемы на примитивные и объектные. С примитивами:

• сужение: (int) someLong молча отбрасывает старшие биты, и 3_000_000_000L превращается в отрицательное число. Если переполнение недопустимо, используйте Math.toIntExact(), он бросит ArithmeticException;
• переполнение до расширения: в long ms = days * 24 * 60 * 60 * 1000 при int days умножение идёт в int и переполняется до присваивания. Лечится литералом 1000L в начале выражения.

С обёртками:

• Integer не приводится к Long: (Long) obj, где внутри Integer, даёт ClassCastException, а Long x = someInteger не компилируется. Частый источник: Jackson кладёт числа в Map<String, Object> как Integer или Long в зависимости от величины;
• equals учитывает тип: Long.valueOf(1).equals(1) возвращает false. Поэтому map.get(1) на Map<Long, V> вернёт null: get принимает Object, аргумент упаковался в Integer, компилятор молчит;
• == на обёртках: сравнивает ссылки. Для значений от -128 до 127 работает кэш, и тест проходит, а на 128 уже нет;
• распаковка null: long x = integerValue при null даёт NullPointerException. Особенно коварно в тернарном операторе, где один операнд Integer, а другой примитив: распаковка там неявная.

Надёжный подход: приводить к одному типу явно через longValue(), сравнивать через equals или Objects.equals и держать ID одного типа по всему коду, от сущности до ключей коллекций.

Где спотыкаются

Утверждают, что Integer нельзя присвоить long без явного приведения. Можно: срабатывает распаковка и затем расширение, именно поэтому и возможен NPE.

Сравнивают Long через ==, потому что «в тестах работало» на маленьких ID.

Используют (int) вместо Math.toIntExact() и получают отрицательные значения без единой ошибки в логах.