Perché il compilatore/JVM non può semplicemente rendere automatico il boxing "funziona"?

Question

Autoboxing è piuttosto spaventoso. Pur comprendendo pienamente la differenza tra == e .equals non posso che aiutare hanno follow bug l'inferno fuori di me:

final List<Integer> foo = Arrays.asList(1, 1000); 
    final List<Integer> bar = Arrays.asList(1, 1000); 
    System.out.println(foo.get(0) == bar.get(0)); 
    System.out.println(foo.get(1) == bar.get(1)); 

che stampa

true 
false 

Perché l'hanno fatto in questo modo? Ha qualcosa a che fare con gli Interi memorizzati nella cache, ma se questo è il caso, perché non si limitano a memorizzare tutti gli Integi usati dal programma? O perché la JVM non si disattiva sempre automaticamente alla primitiva?

La stampa false false o true true sarebbe andata molto meglio.

EDIT

Non sono d'accordo per rottura del vecchio codice. Avendo restituito il valore foo.get(0) == bar.get(0), hai già infranto il codice.

non può risolvere il problema a livello di compilatore sostituendo numeri interi con int in bytecode (fintanto che non viene mai assegnato null)

Answer 1

• Perché l'hanno fatto in questo modo?

Ogni numero intero compreso tra -128 e 127 viene memorizzato nella cache da java. Lo hanno fatto, presumibilmente, per il beneficio delle prestazioni. Anche se volessero tornare su questa decisione ora, è improbabile che lo facciano. Se qualcuno ha creato un codice in base a questo, il suo codice si interromperebbe quando è stato rimosso. Per la codifica hobby, questo forse non importa, ma per il codice aziendale, le persone si arrabbiano e le cause si verificano.

• Perché non memorizzano solo tutti gli interi utilizzati dal programma?

Tutti gli integer non possono essere memorizzati nella cache, poiché le implicazioni della memoria sarebbero enormi.

• Perché la JVM non si disattiva sempre automaticamente alla primitiva?

Perché la JVM non può sapere cosa volevi. Inoltre, questa modifica potrebbe facilmente rompere il codice legacy non creato per gestire questo caso.

Se JVM viene automaticamente rimosso dalle primitive per le chiamate su ==, questo problema diventerà in realtà PIÙ confuso. Ora è necessario ricordare che == confronta sempre i riferimenti agli oggetti, a meno che gli oggetti non possano essere unbox. Ciò causerebbe ancora casi di confusione più strani, proprio come quello che hai affermato sopra.

Invece di preoccuparsi troppo duro su questo, basta ricordare questa regola invece:

MAI confrontare gli oggetti con == a meno che non si ha intenzione di essere confrontandoli con i loro riferimenti. Se lo fai, non riesco a pensare a uno scenario in cui ti imbatti in un problema.

Answer 2

Potete immaginare come prestazioni male sarebbe se ogni Integer portato in testa per internamento? Inoltre non funziona per new Integer.

Il linguaggio Java (non un problema JVM) non può sempre annullare l'invio automatico perché il codice progettato per Java precedente 1.5 deve ancora funzionare.

Answer 3

Integer s nell'intervallo di byte sono lo stesso oggetto, perché sono memorizzati nella cache. Integer s al di fuori dell'intervallo di byte non lo sono. Se tutti gli interi dovessero essere memorizzati nella cache, immagina la memoria richiesta.

E da here

Il risultato di tutta questa magia è che si può in gran parte ignorare la distinzione tra int e Integer, con alcune precisazioni. Un'espressione Integer può avere un valore nullo. Se il tuo programma tenta di autounbox null, genererà una NullPointerException. L'operatore == esegue confronti di identità di riferimento su espressioni Integer e confronti di uguaglianza di valori su espressioni int. Infine, ci sono i costi di prestazioni associati con la boxe e unboxing, anche se viene fatto automaticamente

Answer 4

Se si ignora completamente il boxing automatico, si ottiene comunque questo comportamento.

final List<Integer> foo = 
    Arrays.asList(Integer.valueOf(1), Integer.valueOf(1000)); 
final List<Integer> bar = 
    Arrays.asList(Integer.valueOf(1), Integer.valueOf(1000)); 

System.out.println(foo.get(0) == bar.get(0)); // true 
System.out.println(foo.get(1) == bar.get(1)); // false 

essere più espliciti, se si desidera un comportamento specifico:

final List<Integer> foo = 
    Arrays.asList(new Integer(1), new Integer(1000)); 
final List<Integer> bar = 
    Arrays.asList(new Integer(1), new Integer(1000)); 

System.out.println(foo.get(0) == bar.get(0)); // false 
System.out.println(foo.get(1) == bar.get(1)); // false 

Questa è una ragione, perché Eclipse ha autoboxing come un avvertimento per impostazione predefinita.

Answer 5

Un sacco di persone hanno problemi con questo problema, anche con persone che scrivono libri su Java.

In Pro Java Programming, pochi pollici sotto sono stati l'autore parla di problemi con l'uso di auto-boxed Integers come chiave in una IdentityHashMap, egli utilizza chiavi Integer auto-box in una WeakHashMap. I valori di esempio che utilizza sono maggiori di 128, quindi la sua chiamata di garbage collection ha esito positivo. Se qualcuno dovesse usare il suo esempio e usare valori minori di 128, il suo esempio fallirebbe (a causa della chiave perma-cache).

Answer 6

Quando si scrive

foo.get(0) 

il compilatore non importa come si è creato l'elenco. Guarda solo il tipo in fase di compilazione della lista foo. Quindi, se questo è un elenco < intero, lo tratterà come un elenco < intero, come si suppone debba fare e un elenco < intero restituisce sempre un intero. Se si desidera utilizzare il == allora dovete scrivere

System.out.println(foo.get(0).intValue() == bar.get(0).intValue()); 

non

System.out.println(foo.get(0) == bar.get(0)); 

perché questo ha un significato completamente diverso.