Primitives in Generics (+ the meaning of this)

[Reinier Zwitserloot]

The rather obvious answer would seem to be that implicit this refers to the
inner object, but explicit this defaults to the outer object. You can still
get an explicit this referencing the inner object by using the SAM type as a
qualifier.

Thus:

public class Example {
    public void cancel() { System.out.println("OUTER"); }

    public void runMe() {
        TimerTask t = { ->
            cancel(); //LINE 1
            this.cancel(); //LINE 2
            Example.this.cancel(); //LINE 3
            TimerTask.this.cancel(); //LINE 4
        };
    }
}

In the above example, LINE 1 and LINE 4 cancel the timertask, whereas LINE 2
and LINE 3 just print "OUTER" to sysout.

As has been said, everything is going to either be hard to understand or not
the thing one would expect in certain situations, and this is of course no
different - now there's a difference between unqualified invocation and
this-qualified invocation for method calls, which doesn't normally happen in
java land. In my purely personal opinion on what's going to do the right
thing and be the least surprising the most often, this one nevertheless
wins.

NB: As per the usual lexical scoping rules, if this was say a Runnable and
not a TimerTask, then LINE 1 would also print 'OUTER'.

 --Reinier Zwitserloot



On Fri, Jul 16, 2010 at 7:07 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> > Regardless of that, do you aggree that the statistical evidence, prepared
> by some members of this list, showed that usage of explicit and implicit
> "this" inside anonymous inner SAM subclass creation expressions is
> practically non-existent and is actualy "in the way" of using outer.this
> and/or outer instance members (even a cause of bugs in JDK itself)?
>
> No, I don't agree with this.  What we have is, basically, arguments over
> which
> use cases are more important and which error modes are worse, which are
> almost
> always just opinion contests, just like syntax discussions about which
> alternative "looks more like Java".  Issues such as the one Josh raised
> (where
> TimerTask wants to call cancel()) come up with some frequency; so do
> accidental shadowing of methods like toString() in inner classes.  This
> generally just comes down to a "which error would you rather have"
> question.
> And, given that inner classes *already* suffer from the accidental
> shadowing
> problem, creating a mechanism that goes the other way (even if the other
> way
> is absolutely right!) is even more confusing for Java developers, who now
> have
> to keep track of two separate and inconsistent bits of puzzlerhood.
>
> That said, the questions you raise here (and in your next e-mail) are fair
> and
> we've already planned to devote some thought to it -- but not now, because
> we've got other things that demand our attention more urgently, such as
> refining and implementing the features that are already in the must-have
> column.
>
>
>