Function types versus arrays

[Joshua Bloch]

Neal,

Actually this is a bit too formal/abstract for my tastes.  Show me some code
that would break. I'm looking for something along the lines of the "Why
generic array creation is illegal" example on page 120 of Effective Java
(Second Ed.).  (I believe it was you who first showed me this example.)

      Thanks,

       Josh

On Wed, Feb 17, 2010 at 6:18 PM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Feb 17, 2010 at 5:59 PM, Joshua Bloch <jjb at google.com> wrote:
> > Can you provide a concise proof that it would require reifying generics?
>  It
> > isn't obvious (to me).
>
> Sure.  If you need more formality, I can work on it this weekend.  One
> form of proof goes something like this:
>
> Consider some an existing generic method.  We assume that the existing
> callers of this method do not pass enough information for the body of
> the method to know, at runtime, the actual types of the type
> parameters.  (If needed, I can prove this assumption.)  Now add a
> lambda expression inside the body of the method, with the type
> parameter appearing in its signature.  The JLS says that changes to
> the body of a method are binary compatible.  If function types are
> reified, then the type of this lambda expression is available at
> runtime.  But that contradicts our assumption that existing callers of
> the method do not pass enough information to reify the type parameter.
>
> You might imagine addressing this by disallowing lambdas with type
> parameters in their signature, but this would prevent lots of code
> (for example, the parallel arrays implementation) from using lambdas.
> Lambda expressions are the only way to create values of function type;
> anonymous inner classes are not an implementation alternative.
> Therefore, the restriction would prevent the parallel arrays API from
> using function types.
>
> -Neal
>