Java Generics — от ‹int› до ‹Integer›

На пути изучения Java Generics я застрял в одном месте.
Было написано: «Java Generics работает только с объектами, а не с примитивными типами».

e.g 

 Gen<Integer> gen=new Gen<Integer>(88);     // Works Fine ..

Но с примитивными типами, такими как int, char и т.д....

 Gen<int> gen=new Gen<int>(88) ;    // Why this results in compile time error

Я имею в виду, поскольку дженерики java имеют функцию автоматической упаковки и распаковки, то почему эту функцию нельзя применить, когда мы объявляем определенный тип для нашего класса?

Я имею в виду, почему Gen<int> автоматически не преобразуется в Gen<Integer>?

Пожалуйста, помогите мне развеять это сомнение.
Спасибо.


java generics type-erasure primitive-types
person Saurabh Gokhale    schedule 15.02.2011    source источник
comment
возможный дубликат синтаксиса Generics: классы и примитивные типы данных   -  person    schedule 15.02.2011
comment
Если вам действительно нужно использовать примитивы, используйте Trove.   -  person st0le    schedule 15.02.2011

Ответы (4)


arrow_upward
10
arrow_downward

Autoboxing не говорит, что вы можете использовать int вместо Integer. Autoboxing автоматизирует процесс упаковки и распаковки. Например. Если мне нужно сохранить какой-то примитивный int в коллекции, мне не нужно создавать объект wrpper вручную. Об этом позаботился компилятор Java. В приведенном выше примере вы создаете экземпляр универсального объекта целочисленного типа. Этот универсальный объект по-прежнему будет нормально работать с int, но объявление int как универсального типа неверно. Обобщения допускают только ссылки на объекты, а не на примитивы.

person mittalpraveen    schedule 15.02.2011
comment
Если я не ошибаюсь, об этом на самом деле заботится компилятор, а не JVM. - person Alain Pannetier; 15.02.2011
comment
@Alain Pannetier - Верно, но вряд ли это спор здесь. (Хотя я дописал твой комментарий!) - person user183037; 15.02.2011

arrow_upward
3
arrow_downward

Как вы обнаружили, вы не можете указать примитивный тип в качестве параметра типа в дженериках Java. Почему это так? Она подробно обсуждается во многих местах, в том числе ошибка Java 4487555.

person sjr    schedule 15.02.2011
comment
Вуху. База данных ошибок Java возвращается! - person Stephen C; 15.02.2011
comment
Я должен был серьезно задуматься :P - person sjr; 15.02.2011
comment
Ссылка мертва =[ - person Troyseph; 15.06.2021

arrow_upward
2
arrow_downward

Простое объяснение: дженерики определяются таким образом.

Веская причина с точки зрения Java: это упрощает стирание типов и преобразование в байтовый код для компилятора. Все, что нужно компилятору, — это приведение типов.

С не-примитивами компилятор должен был бы решить, следует ли приводить или отправлять в папку «Входящие/исходящие», ему потребовались бы дополнительные правила проверки (extends и & не имели бы смысла с примитивами, должен ли ? включать примитивы, да или нет? и т. д.) и должны обрабатывать преобразования типов (предположим, вы параметризуете коллекцию с помощью long и добавляете int...?)

Хорошая причина с точки зрения программиста: операции с плохой производительностью остаются видимыми! Разрешение примитивов в качестве аргументов типа потребует скрытой автоупаковки (входящая упаковка для сохранения, исходящая упаковка для операций чтения. Входящая упаковка может создавать новые объекты, что является дорогостоящим. Люди ожидают быстрых операций, если они параметризируют общий класс с примитивами, но было бы верно и обратное.

person Andreas Dolk    schedule 15.02.2011

arrow_upward
0
arrow_downward

Это очень хороший вопрос.

Как вы и подозревали, абстракцию наверняка можно распространить на параметры типа и сделать их прозрачными для программиста. На самом деле это то, что делают большинство современных языков JVM (конечно, статически типизированные). Примеры включают Scala, Ceylon, Kotlin и т. д.

Вот как будет выглядеть ваш пример в Scala:

val gen: Gen[Int] = new Gen[Int](80)

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

Что касается того, почему люди Java не сделали этого... Я на самом деле не знаю причины, но я полагаю, что такая абстракция не соответствовала бы существующей спецификации Java, не усложняя семантику (или не жертвуя обратной совместимостью, что, безусловно, не рабочий вариант).

person missingfaktor    schedule 07.08.2011