There are two cases I am aware of when local #0 does not refer to this
:
- In static methods, as documented by @JonSkeet.
- In instance methods where local #0 has been overwritten by some value other.
The second case is perfectly valid. Local #0 is only guaranteed to reference this
upon entry to an instance method. Within the method, there is nothing inherently "special" about slot #0; it may be (re)written like any other slot (as can those used by formal parameters). Consider the following example in Jasmin format:
.class public HelloWorld
.super java/lang/Object
.method public <init>()V
.limit stack 2
aload_0
invokenonvirtual java/lang/Object/<init>()V
ldc "Hello World."
astore_0
getstatic java/lang/System/out Ljava/io/PrintStream;
aload_0
invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
return
.end method
.method public static main([Ljava/lang/String;)V
.limit stack 2
new HelloWorld
invokenonvirtual HelloWorld/<init>()V
return
.end method
In HelloWorld/<init>()V
, we overwrite local #0 with a constant string. Thus, the second use of aload_0
loads a value other than a this
pointer. It is not unusual for the same local slot to refer to different "conceptual" variables at different points in the code, especially if a class has been run through a bytecode optimizer.
So, in answer to your question: yes, there is at least one other counterexample.