This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I think seetharaman is right. If the variable i had been private, then you wouldn't be able to reach it. And you wouldn't be able to reach it by prefixing with super either. Also if your variable had been overriden, then you'd have a difference between this.i and super.i.
You are quite right, Henrique Ordine, except that you shouldn't say "overridden." The variable is "hidden;" Joshua Bloch in Effective Java shows that you can get subtle errors from hidden class members, and warns against hiding. See this FAQ.
This brings up a question I've had for a long time: Why don't PC compilers give a symbol cross reference as part of the compile process. Then you could easily see the scope of the variable that you think is local really belongs to the super.
You miss my point about a symbol cross reference. It has nothing to do with compiler errors. The cross reference listing for a symbol would show where the symbol was defined and where it was used. In the above discussions there was doubt about where a symbol was defined. A cross reference would show where the symbol was defined and remove the doubt.
Originally posted by Norm Radder: A cross reference would show where the symbol was defined and remove the doubt.
Yes, indeed, although I don't know how many people these days would have the patience to go through it! Here's a bog entry in which I talk about another unpopular solution to this same kind of problem. Read the comments, where people bring up both syntax-coloring and compiler warnings as additional ways to address it.