First draft of translation document

[Brian Goetz]

>   - The closure$1 method is static yet seems to be trying to access the
> "bottom" and "top" fields of the B2.Closure$1 class.

Typo.  In the "translation as inner class" approach, the closure methods 
should be instance methods.

>   - B2.Closure$1 implements Filter but presuming closure$1 was not meant
> to be static, unless "closure$1" is the actual name of the one method in
> the Filter SAM, "closure$1" is the wrong name. Presumably it should be
> called "filter" or some such.

Right, derived from the same cut and paste bug as above typo.

>   - Filter's signature is Filter<T>, and its one method takes a T. that
> method's erased signature would be (Ljava/lang/Object;)Z, and that's
> what list.filter() will be working with, not (LPerson;)Z. Javac's
> standard strategy here is to make filter(Person) the 'true' method and
> generate a bridge method with signature filter(Object) which simply
> wraps a call on to the true filter(Person), along with a cast. Given
> that the most likely place that closure object will end up will use only
> the bridge method, this seems needlessly inefficient. Is it perhaps
> possible to generate only the filter(Object) variant?

It would be possible, though the status quo it is not as inefficient as you 
might imagine.  The bridge method filter(Object) dispatches to filter(Person), 
and in most cases class hierarchy analysis demonstrates that neither 
filter(Object) nor filter(Person) are overridden, and can be inlined by the 
VM.  Even if filter(Person) is big (thus blowing the inlining budget), 
filter(Object) is not, and so it will be frequently inlined at the call site 
to filter(Object), eliminating the overhead you cite (also, inlining 
filter(Object) often exposes the opportunity to eliminate the cast check). 
Trust the VM!