Analizzando il bytecode di questa classe semplice, sono giunto alla conclusione che il compilatore non conserva alcuna informazione su una variabile locale che è final
. Ciò sembra strano, dal momento che ritengo che il compilatore HotSpot possa effettivamente utilizzare queste informazioni per fare ottimizzazioni.Modificatore 'finale' variabile perso in Bytecode?
Codice:
public static void main(String[] args)
{
final int i = 10;
System.out.println(i);
}
Bytecode:
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=1
0: bipush 10
2: istore_1
3: getstatic #16 // Field java/lang/System.out:Ljava/io/PrintStream;
6: bipush 10
8: invokevirtual #22 // Method java/io/PrintStream.println:(I)V
11: return
LineNumberTable:
line 7: 0
line 8: 3
line 9: 11
LocalVariableTable:
Start Length Slot Name Signature
0 12 0 args [Ljava/lang/String;
3 9 1 i I
v'è alcuna ragione specifica non mantenere le bandiere di accesso di una variabile locale, diversa risparmiare spazio sul disco? Perché per me, sembra che essere final
sia una proprietà relativamente non banale di una variabile.
SIC hotspot trasformano il bytecode in una rappresentazione SSA internamente, che AIUI rende superfluo finalness comunque. E ci sono altre finzioni in java-land che non sono reali a livello di bytecode, ad es. generici – the8472
Ha senso per i generici, dal momento che avrebbero rotto la compatibilità verso il basso, ma 'finale' è stato lì fin dall'inizio. – Clashsoft
le eccezioni controllate sarebbero un altro esempio. – the8472