Autoboxing: Je peux donc écrire: Integer i = 0; au lieu de: Integer i = new Integer (0);

Question

Autoboxing semble venir au fait que je peux écrire:

Integer i = 0; 

au lieu de:

Integer i = new Integer(0);

Ainsi, le compilateur peut convertir automatiquement une primitive à un objet.

Est-ce que l'idée? Pourquoi est-ce important?

Answer 1

sorte de simplifié un peu trop.

Autoboxing est également en jeu lors de l'utilisation des collections. Comme expliqué dans les docs java du soleil:

  

Les collections ne peuvent contenir que des références d'objet, vous devez donc à la boîte de valeurs primitives dans la classe d'emballage approprié. ... Lorsque vous prenez l'objet de la collection, vous obtenez le nombre entier que vous mettez; si vous avez besoin d'un int, vous devez unbox l'entier en utilisant la méthode intValue. Tout cela est la boxe et unboxing une douleur et encombrent votre code. La fonction autoboxing et unboxing automatise le processus, ce qui élimine la douleur et l'encombrement.

     

Alors, quand devriez-vous utiliser autoboxing et unboxing? Utilisez-les seulement quand il y a une « différence d'impédance » entre les types de référence et primitives, par exemple, lorsque vous devez mettre des valeurs numériques dans une collection. Il ne convient pas d'utiliser autoboxing et unboxing pour le calcul scientifique, ou tout autre code numérique sensible à la performance. Est un nombre entier pas un substitut pour un int; autoboxing et unboxing brouillent la distinction entre les types primitifs et les types de référence, mais ils ne l'éliminent pas.

Grande vue d'ensemble des Autoboxing

Answer 2

BTW

Integer i = 0;

est équivalent à

Integer i = Integer.valueOf(0);

La distinction est que valueOf () ne crée pas un nouvel objet pour les valeurs entre -128 et 127 (Apparemment, ce sera accordable si Java 6u14)

Answer 3

Il existe de sorte que vous pouvez écrire du code comme

List<Integer> is = new ArrayList<Integer>();
is.add(1); // auto-boxing
is.add(2);
is.add(3);

int sum = 0;
for (int i : is)  // auto-unboxing
{
    sum += i;
}

Pour les entiers simples, vous devriez par défaut le type int, pas entier. Entier est la plupart du temps pour une utilisation dans les collections.

Méfiez-vous qu'un long est différent de la même valeur que d'un nombre entier (à l'aide equals ()), mais comme un temps il est égal à un entier (en utilisant ==).

Answer 4

Telle est l'idée, oui. Il est encore plus pratique pour être en mesure d'attribuer un nombre entier à un int, cependant.

On pourrait faire valoir que les adresses autoboxing un symptôme plutôt qu'une cause. La véritable source de confusion est que le système de type Java est incompatible: la nécessité pour les primitives et les références d'objets est artificiel et maladroit. Autoboxing pallie que peu.

Answer 5

Avec mon chapeau cynique: pour le maquillage des limites imposées à la spécification Java (je veux dire ici Chêne) d'origine. Non seulement la première fois.

Answer 6

Makes pour le code plus lisible et plus propre. Surtout si vous faites des opérations (depuis Java ne pas surcharger l'opérateur).

Answer 7

D'après ce que je me souviens de la lecture efficace Java de Joshua Bloch, vous devriez considérer les primitives sur leurs homologues en boîte. Autoboxing sans tenir compte de ses effets secondaires peuvent produire des problèmes.

Answer 8

Ajout au commentaire de Lim, primitives sont stockées sur la pile, et-emballages primitifs, comme des objets, sont stockés sur le tas ... Il y a des implications subtiles en raison de cela.

Answer 9

Le principal avantage serait la lisibilité, le sucre syntaxique essentiellement. Java est déjà très bavard, Sun essaie toutes sortes de façons de rendre la syntaxe plus courte.