Pourquoi les gens utilisent encore des types primitifs en Java ?

Question

Depuis Java 5, nous avons eu boxing/unboxing de types primitifs de sorte qu' int est enveloppé d'être java.lang.Integer, et si, et et ainsi de suite. Je vois beaucoup de nouveaux projets Java dernièrement (qui certainement besoin d'un JRE d'au moins la version 5, si ce n'6) qui sont à l'aide de int plutôt que d' java.lang.Integer, mais il est beaucoup plus commode à utiliser ce dernier, comme il a quelques méthodes d'assistance pour la conversion à l' long valeurs et coll. Pourquoi certains encore utiliser les types primitifs en Java? Est-il un avantage tangible?

Answer 1

Dans Joshua Bloch est Efficace Java, Article 5: "Éviter de créer des objets inutiles", il affiche l'exemple de code suivant:

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for(long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

et il faut 43 secondes pour s'exécuter. Prendre le temps dans la primitive qu'elle ramène à 6,8 secondes... si c'est une indication pourquoi nous utilisons des primitives.

Le manque de valeur native de l'égalité est également un sujet de préoccupation (.equals() est assez détaillé par rapport à l' ==)

pour biziclop:

class biziclop {

    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

Résultats:

C:\Documents and Settings\glow\My Documents>java biziclop
false
false
true
false

C:\Documents and Settings\glow\My Documents>

Answer 2

Autounboxing peut rendre difficile de NPE spot

Dans la plupart des situations l’affectation de nulle à `` est beaucoup moins évident que ci-dessus.

Answer 3

Types de boîte ont de moins bons résultats et exigent davantage de mémoire.

Answer 4

Types primitifs :

Maintenant évaluer :

Il a `` . Rien d’étonnant. Maintenant, essayez les types boxed :

Maintenant évaluer :

Il a `` . Sans doute. Dépend de l’exécution. Est cette raison assez ?

Answer 5

En plus de la performance et des problèmes de mémoire, j'aimerais venir avec une autre question: L' List interface serait rompu sans int.
Le problème est que les surchargées remove() méthode (remove(int) vs remove(Object)). remove(Integer) serait toujours résoudre à l'appel de ce dernier, de sorte que vous ne pouvez pas supprimer un élément à l'index.

D'autre part, il y a un écueil à éviter lorsque vous essayez d'ajouter et de supprimer un int:

final int i = 42;
final List<Integer> list = new ArrayList<Integer>();
list.add(i); // add(Object)
list.remove(i); // remove(int) - Ouch!