Function types versus arrays
Neal Gafter
neal at gafter.com
Wed Feb 17 21:56:26 PST 2010
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.
More information about the lambda-dev
mailing list