Qu'est-ce que l'autoboxing et quels en sont les pièges ?

Question

Accepted Answer

**L'autoboxing** est la conversion automatique de Java entre les **primitives** (`int`, `double`) et leurs **objets wrapper** (`Integer`, `Double`). C'est pratique mais comporte des pièges subtils — surcharge de performance, comportement surprenant de `==`, et risque de `NullPointerException`. ## Autoboxing et unboxing ```java Integer boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42)) int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue()) List nums = new ArrayList<>(); nums.add(5); // autoboxes int 5 → Integer (collections need objects) int x = nums.get(0); // auto-unboxes Integer → int ``` Cela se produit automatiquement car les collections et les génériques nécessitent des objets (on ne peut pas avoir `List`), donc Java encapsule les primitives de manière transparente. ## Piège 1 : == compare les références, pas les valeurs, pour les wrappers ```java Integer a = 1000; Integer b = 1000; a == b; // ❌ FALSE — different Integer OBJECTS (reference comparison) a.equals(b); // ✅ true — value comparison // the WORSE trap — the Integer cache makes small values seem to work: Integer c = 100, d = 100; c == d; // TRUE — Java CACHES Integers from -128 to 127 (same object) Integer e = 200, f = 200; e == f; // FALSE — outside the cache range → different objects ``` C'est insidieux : `==` sur `Integer` fonctionne pour les petites valeurs (en cache) mais **échoue pour les grandes** — du code qui semble correct en test se casse en production. Utilisez toujours `.equals()` pour comparer les valeurs des wrappers, ou déboîtez d'abord les primitives. ## Piège 2 : NullPointerException lors du unboxing ```java Integer value = null; // a wrapper can be null int x = value; // 💥 NullPointerException — unboxing null calls null.intValue() Map map = new HashMap<>(); int count = map.get("missing"); // 💥 NPE — get() returns null, then unboxing fails ``` Déboîter un wrapper `null` lève une NPE — un crash courant et surprenant, particulièrement avec les recherches dans des maps qui retournent null. ## Piège 3 : surcharge de performance ```java // ❌ autoboxing in a hot loop — creates millions of Integer objects (GC pressure, slow) Long sum = 0L; // WRONG type — wrapper for (long i = 0; i < 1_000_000; i++) { sum += i; // unbox, add, re-box → new Long each iteration! } // ✅ use primitives in hot paths long sum = 0L; // primitive — no boxing ``` Le boxing/unboxing répété crée des objets excessifs, nuisant à la performance dans les boucles serrées. ## Pourquoi c'est important L'autoboxing est pratique et omniprésent (les collections, les génériques en dépendent tous), mais ses pièges causent de vrais bugs difficiles à diagnostiquer. Le **piège `==`** est particulièrement dangereux : comparer des `Integer`s avec `==` fonctionne pour les petites valeurs en cache (-128 à 127) mais échoue silencieusement pour les plus grandes — un bug qui passe les tests et se casse en production — rendant `.equals()` (ou le déboîtage) essentiel pour la comparaison des wrappers. Les **NullPointerExceptions** provenant du unboxing de wrappers null (courant avec les recherches dans des maps) sont un autre crash fréquent. Et le boxing dans les **boucles critiques** crée des objets inutiles, nuisant à la performance. Comprendre quand le boxing se produit, le problème de comparaison valeur-vs-référence, le risque du unboxing null, et utiliser les primitives dans le code critique pour la performance est important pour écrire du Java correct et efficace — et le comportement `==` du cache Integer est une question classique d'entretien qui révèle une compréhension profonde.