Почему Наборы Java не могут непосредственно сохранить типы Примитивов?
Наборы Java только хранят Объекты, не типы примитивов; однако мы можем сохранить классы обертки.
Почему это ограничение?
5 ответов
Это было дизайнерское решение Java, которое некоторые считают ошибкой. Контейнеры хотят, чтобы объекты и примитивы не были производными от Object.
Это то место, которое разработчики .NET узнали из JVM и реализовали типы значений и обобщения, так что во многих случаях упаковка исключена. В среде CLR универсальные контейнеры могут хранить типы значений как часть базовой структуры контейнера.
Java решила добавить 100% универсальную поддержку в компилятор без поддержки со стороны JVM. JVM, какова она есть, не поддерживает "не-объектный" объект. Дженерики Java позволяют вам притвориться, что обертки нет, но вы все равно платите цену производительности бокса. Это ВАЖНО для определенных классов программ.
Бокс - это технический компромисс, и я чувствую, что детали реализации просачиваются в язык. Автобоксинг - хороший синтаксический сахар, но по-прежнему снижает производительность. Во всяком случае, я бы хотел, чтобы компилятор предупреждал меня, когда он автоматически упаковывается. (Насколько я знаю, возможно, сейчас я написал этот ответ в 2010 году).
Хорошее объяснение SO по поводу бокса: Почему некоторым языкам нужна упаковка и распаковка?
И критика дженериков Java: Почему некоторые утверждают, что реализация дженериков в Java плохая?
В защиту Java легко оглянуться назад и критиковать. JVM выдержала испытание временем и во многих отношениях является хорошей разработкой.
Существует концепция автоматической упаковки и автоматической распаковки. Если вы попытаетесь сохранить int в List , компилятор Java автоматически преобразует его в Integer .
На самом деле это не ограничение, не так ли?
Подумайте, хотите ли вы создать коллекцию, в которой хранятся примитивные значения. Как бы вы написали коллекцию, которая может хранить либо int, либо float, либо char? Скорее всего, у вас будет несколько коллекций, поэтому вам понадобятся intlist и charlist и т. Д.
Воспользовавшись объектно-ориентированной природой Java, когда вы пишете класс коллекции, он может хранить любой объект, поэтому вам понадобится только одна коллекция класс. Эта идея, полиморфизм, очень мощная и значительно упрощает дизайн библиотек.
Это комбинация двух фактов:
- Примитивные типы Java не являются ссылочными типами (например,
intне являетсяObject) - Java делает универсальные типы, использующие стирание типов ссылок (например,
Listна самом деле являетсяListво время выполнения)
Поскольку оба эти типа верны, универсальные коллекции Java не могут хранить примитивные типы напрямую. Для удобства введена автобоксинг, позволяющая автоматически заготовить примитивные типы в ссылонные типы. Не заблуждайтесь, однако, коллекции по-прежнему хранят ссылки на будут ссылаться на будут быть объектами.
Можно ли было этого избежать? Может быть.
- Если
intявляется объектомObject, то нет никакой необходимости в типах коробок. - Если универсальные шаблоны не используются стирания типов, то примитивы могут использоваться для параметров типа.
Упрощает реализацию. Поскольку примитивы Java не считаются объектами, для каждого из этих примитивов потребуется создать отдельный класс коллекции (без кода шаблона для совместного использования).
Конечно, вы можете сделать это, просто посмотрев GNU Trove, Apache Commons Primitives или HPPC.
Если у вас нет действительно больших коллекций, накладные расходы для оберток не имеют достаточного значения для людей(и когда у вас есть действительно большие примитивные коллекции, вы можете потратить усилия, чтобы посмотреть на использование / создание специализированной структуры данных для них).