Analysieren der Bytecode dieser einfachen Klasse, bin ich zu dem Schluss gekommen, dass der Compiler keine Informationen über eine lokale Variable final
behält. Dies scheint jedoch seltsam, da ich glaube, dass der HotSpot-Compiler diese Informationen tatsächlich dazu verwenden kann, Optimierungen vorzunehmen.Variabler "endgültiger" Modifikator in Bytecode verloren?
-Code:
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
Gibt es einen bestimmten Grund nicht die Zugriffs-Flags einer lokalen Variablen, die nicht zu halten Speicherplatz sparen? Weil es für mich scheint, dass final
eine relativ nicht-triviale Eigenschaft einer Variablen ist.
Hotspot JITs verwandeln den Bytecode in eine SSA Darstellung intern, die AIUI finalness redundante ohnehin macht. Und es gibt andere Fiktionen in Java-Land, die auf Bytecodeebene nicht real sind, z. Generika – the8472
Es macht Sinn für Generika, da sie Abwärtskompatibilität gebrochen hätten, aber "final" war von Anfang an dabei. – Clashsoft
checked Ausnahmen wäre ein anderes Beispiel. – the8472