Function types versus arrays

[Joshua Bloch]

Neal,

Thanks.  This example makes the problem clear.

     Josh

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

> On Wed, Feb 17, 2010 at 6:56 PM, Joshua Bloch <jjb at google.com> wrote:
> > 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.)
>
> Since reification of function types is visible by its effect in arrays
> (project lambda hasn't yet described the reflective APIs), we can
> illustrate the problem this way:
>
> class Ex {
>    static #String()[] array = new #String()[1];
>    static Object[] objectArray = array;
>    static <T> void impossible() {
>        final T t = null;
>        objectArray[0] = #()(t); // assign a function of type #T()
> into objectArray
>    }
> }
>
> Now, if we call Ex.<String>impossible(), the code should run without
> problems (the lambda inside is of type #String()).
>
> If we call Ex.<Integer>impossible(), the code must throw an array
> store exception (the lambda inside is of type #Integer()).
>
> Both calls must generate the exact same bytecode due to erasure of
> generics and the existing binary compatibility rules.
>
> Since the same code must behave differently at runtime due to
> information that is unavailable at runtime, we have a logical
> contradiction.
>