Of course, this can not apply here. Right. I meant "if (hypothetically) we
were in a context where the outer class has an associated 'this' reference, we would have to use OuterClassName.this"
I'm sort of confused by OuterClassName.this. It's counterintuitive because OuterClassName is a reference to a class, right?. Ummm... depends what you mean. I'm assuming that there's an outer class, and its name is "OuterClassName". I could say "OuterClassName" is a "reference" to the outer class, in the sense that the name refers to the class. In ordinary human language I would call it a reference. But it's not a
reference in the Java sense - it's not a bit of data in memory somewhere which points to an instance of a class. In this context "OuterClassName" is just a
string which is part of a larger expression. The complete expression OuterClassName.this
will be a
reference - it will refer to a specific instance of the class OuterClassName, and it (the reference) can be passed around to other variables, methods, classes to tell other parts of the program what specific instance we're dealing with.
The syntax with the . is probably confusing. It looks similar to "obj.method()" or "obj.field". In both these cases, obj is a reference to an object of some class. But the dot is used in other contexts in which the thing to the left of the dot is not necessarily a reference. E.g. in "ClassName.staticMethodCall()", "ClassName" isn't a reference (in the Java sense), it's a qualifier which says "the static method staticMethodCall() is defined in class ClassName; look for it there". And in "OuterClassName.this" OuterClassName isn't a reference in the Java sense - it's a qualifier that says "the 'this' that I'm talking about is the associated instance of the class OuterClassName,
not the associated instance of WhateverTheInnermostClassIs, as you would otherwise expect." (Bet you didn't think a dot could be so wordy, eh?)
The applicable JLS section is
here.
value is referred from the enclosing instance of OuterC, but what I find odd is that the instance is the anonymous inner Runnable. Yeah. In the original version there were two different variables named "value", and inside the printClassInfo() method the local variable took precedence. That is, when you said "value" it assumed that you meant the one that had just been defined in that method, rather than the one that had been defined further out in the outer class. But when you comment out the local variable, it turns out that the outer class instance variable
was in scope and accessible - it was just ignored as long as there was a more local variable with the same name. The local variable is said to
shadow the other variable.
In the first version of your code, if you want to refer to the "other" value from within method printClassInfo() (while it still has an unrelated local variable "value"), you have use a longer qualified name: "OuterC.this.value". Here "OuterC.this" is a reference to the OuterC instance (the one created with "new OuterC()") and ".value" accesses the field value for that instance.