Function types versus arrays

[Artur Biesiadowski]

Rémi Forax wrote:
> For the record the problem is:
>
> #String(String)[] arrayOfFunction = new #String(String)[10];
> Object[] array = arrayOfFunction;
> array[0] = #int() (2);
>
> The last line should raise an array store exception.
> So the VM should be aware of the precise type of the array of function.
>
> Currently, neither the anonymous class translation nor the method handle one
> provide reified function type so array of function types are unsafe.
>   
What about having auto-generated interfaces (abstract classes?) 
representing lambdas in well known place? Something like java.gen.*, 
with names being equal to signature of the lambda (escaped/encoded as 
needed). It would require considerably trickery to allocate them in most 
parent possible classloader (so all java.* +primitives would go to root 
classloader, anything referencing application classes would have to stay 
there) - but not too high, as multiple classloaders can load distinct 
classes with same names. Could be probably done purely on classloader 
code, even without jvm support (for the interface lookup/generation at 
least).

I think it would solve arrays issues. Problem is polluting the top-level 
classloader with loads of primitive/core lambda types, but I don't think 
it is a showstopper.


Regards,
Artur Biesiadowski