Почему нельзя использовать примитивы в дженериках (например, Map<int, int>)?

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

Потому что дженерики в Java — это механизм времени компиляции, а примитивы не являются объектами и не могут быть представлены как Object во время выполнения.

Подробное объяснение

1. Типизационное стирание (Type Erasure)

Java реализует дженерики через type erasure — это означает, что во время выполнения (runtime) вся информация о типах-параметрах стирается, и дженерик-код превращается в обычный код с использованием Object.

Например:

List<String> list = new ArrayList<>();

во время выполнения становится просто:

List list = new ArrayList(); // тип String "стирается"

Поскольку примитивы (int, boolean, char и т.д.) не являются подтипами Object, их нельзя использовать там, где JVM ожидает ссылочный тип.

💡 Компилятор не может заменить int на Object, потому что int — это не объект, а 32-битное значение в стеке или регистре.

2. Память и представление данных

• Примитивы хранятся непосредственно (в стеке или внутри объекта).
• Объекты (включая Integer, Boolean и т.д.) — это ссылки на кучу (heap).

Если бы List<int> существовал, JVM пришлось бы:

• Хранить примитивы внутри массива ссылок, что невозможно напрямую;
• Или создавать специализированные версии коллекций для каждого примитива — как в C++ (templates) или в проектах типа Project Valhalla (см. ниже).

Но Java пошла другим путём — ради совместимости и простоты VM.

3. Автоматическая упаковка (Autoboxing) — частичное решение

Java предоставляет обёртки (wrapper classes):

• int → Integer
• boolean → Boolean
• double → Double
• и т.д.

И автоматически преобразует между ними:

List<Integer> list = new ArrayList<>();

list.add(42); // int → Integer (autoboxing)

int x = list.get(0); // Integer → int (unboxing)

✅ Это позволяет использовать примитивы "как бы" в дженериках.
❌ Но с накладными расходами:

• Выделение памяти в куче для каждого Integer;
• Дополнительные операции упаковки/распаковки;
• Возможность NullPointerException, если null попадёт в Integer.

✅ Плюсы запрета примитивов в дженериках

Плюс

Объяснение

Простота JVM

Не нужно поддерживать специализированные версии классов для каждого типа.

Обратная совместимость

Код с дженериками (после стирания) совместим с Java 1.4 и раньше.

Единая иерархия типов

Все дженерик-типы — подтипы Object, что упрощает reflection и обобщённые алгоритмы.

❌ Минусы

Минус

Объяснение

Производительность

Упаковка/распаковка (boxing/unboxing) создаёт накладные расходы, особенно в циклах и коллекциях.

Потребление памяти

List<Integer> занимает в 3–4 раза больше памяти, чем массив int[].

Ошибки времени выполнения

NullPointerException при null в обёртке (Integer i = null; int x = i; // NPE!).

Неудобство

Приходится писать Map<Long, Double> вместо Map<long, double>.

💡 Альтернативы для высокой производительности

Если вам критична производительность (например, в числовой обработке, ML, играх), используйте:

• Специализированные библиотеки:Eclipse Collections — IntList, LongIntMap и т.д.
  FastUtil — Int2IntOpenHashMap
  Trove — TIntIntHashMap
  

Пример с FastUtil:

Int2IntOpenHashMap map = new Int2IntOpenHashMap();

map.put(1, 100);

int value = map.get(1); // без упаковки!

Эти библиотеки хранят примитивы напрямую в массивах, избегая упаковки.

✅ Вывод

Дженерики не поддерживают примитивы из-за архитектурного выбора Java: type erasure + единая объектная модель.
Это упрощает JVM и сохраняет совместимость, но жертвует производительностью.
Для критичных случаев — используйте специализированные коллекции.

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