Génériques Java - & lt; int & gt; à & lt; Entier & gt;

Dans la voie de l'apprentissage de Java Génériques, je me suis coincé à un point.
Il a été écrit "Java Génériques fonctionne uniquement avec les Objets et non les types primitifs".

e.g

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

Mais, avec les types primitifs comme int,char, etc ...

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

Je veux dire, depuis java génériques n'ont de l'auto-boxing & unboxing fonctionnalité, alors pourquoi cette fonction ne peut pas être appliquée lors de la déclaration d'un type spécifique de notre classe ?

Je veux dire, pourquoi Gen<int> n'est pas
automatiquement converties en
Gen<Integer> ?

Merci de m'aider à dissiper ce doute.
Merci.

source d'informationauteur Javascript is GOD | 2011-02-15

  1. 9

    L'autoboxing ne veut pas dire que vous pouvez utiliser int au lieu d'un Entier. L'autoboxing automatise le processus de boxing et unboxing. E. g. Si j'ai besoin de stocker des primitives de type int à une collection, je n'ai pas besoin de créer de la wrpper objet manuellement. Son été pris en charge par le compilateur Java. Dans l'exemple ci-dessus, vous êtes l'instanciation d'un objet générique qui est de type Entier. Cet objet générique fonctionnera toujours bien int mais déclarant int comme un type générique est faux. Les génériques permettent seulement de l'objet de référence non les primitives.

  2. 3

    Que vous avez découvert, vous ne pouvez pas parler d'un type primitif comme un paramètre de type Java génériques. Pourquoi est-ce le cas? Il est discuté en détail dans de nombreux endroits, y compris Bug de Java 4487555.

  3. 2

    L'explication simple: les Génériques sont définis de cette façon.

    Une bonne raison de la perspective Java: Il simplifie le type d'effacement, de traduction, de byte code pour le compilateur. Tout le compilateur a besoin de faire est de quelques casting.

    Avec les non-primitives le compilateur aurait à décider de la fonte ou de la boîte de réception/boîte d'envoi, il aurait besoin d'avoir plus de la validation des règles (extends et & n'aurait plus de sens avec les primitives, si un ? incluent les primitives, oui ou non? et ainsi de suite) et avez à gérer les conversions de type (à supposer que vous parametize une collection avec long et ajouter un int...?)

    Une bonne raison à partir d'un des programmeurs de point de vue: opérations avec une mauvaise performance sont conservés visible! Permettant primitves comme Arguments de Type nécessiterait caché l'autoboxing (inboxing pour stocker, outboxing pour les opérations de lecture. Inboxing peut créer de nouveaux objets qui est cher. Gens s'attendent à ce rapide opérations si elles parametize d'une classe générique avec des primitives, mais le contraire serait vrai.

  4. 0

    C'est une très bonne question.

    Comme vous soupçonne, l'abstraction pourrait sûrement être étendu pour les paramètres de type et de trasparent pour le programmeur. En fait, c'est ce qui est le plus moderne de la JVM langues (statiquement typé, bien entendu). Les exemples incluent la Scala, de Ceylan, de Kotlin etc.

    C'est ce que votre exemple pourrait ressembler à Scala:

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

    Int est juste une classe ordinaire, comme les autres classes. Il n'y a pas de primitive de l'objet distinction d'aucune sorte.

    Pourquoi Java gens ne l'ont pas fait... je ne sais pas vraiment la raison, mais j'imagine que cette abstraction ne correspond pas avec la spécification de Java sans surcharger la sémantique (ou sans sacrifier la compatibilité descendante, qui n'est certainement pas une option viable).