Casting reference array to any-T array.

[Vitaly Davidovich]

>
> Tentatively so.  We still have to figure out how to generate the right set
> of warnings, and the right conditions for suppressing those warnings, since
> we don't want to undermine the invariant that "if a program compiles with
> no (suppressed or not) raw or unchecked warnings, then the casts inserted
> by the compiler will not fail."
> As an alternative to doing it in the language, we will also consider
> instead providing pre-peeled library methods like:


>   <any T> T[] newArray(int)


Ideally, "new T[]" would be made work as it's cleaner/"purer", although a
lib method isn't too big of a deal.


> The current functionality continues with the erasure plan.  However, I
> wouldn't mind doing better!


Yeah, I can't immediately think of a critical reason why it can't stay
erased.  For JIT optimizer, having a narrower upper bound on the type may
make its life easier, although I don't know if it'll have any material
difference.  The one question is what reflection will do (and any code
based on reflection, such as custom serialization, code generation, etc):

<any T> T[] getArray() {
   return new T[];
}

Object someArray = getArray<int>();
someArray.getClass().getComponentType() == int.class

someArray = getArray<MyValueType>();
someArray.getClass().getComponentType() == MyValueType.class

someArray = getArray<Foo>(); // Foo is a class or interface, doesn't matter
someArray.getClass().getComponentType() == Object.class

The asymmetry would be unfortunate, I think.

On Wed, Jan 7, 2015 at 4:48 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Timely response - I was just writing to confirm that "new T[]" construct
>> will be supported.
>>
>
> Tentatively so.  We still have to figure out how to generate the right set
> of warnings, and the right conditions for suppressing those warnings, since
> we don't want to undermine the invariant that "if a program compiles with
> no (suppressed or not) raw or unchecked warnings, then the casts inserted
> by the compiler will not fail."
>
> As an alternative to doing it in the language, we will also consider
> instead providing pre-peeled library methods like:
>
>   <any T> T[] newArray(int)
>
>  As a side note, is the plan to continue erasing T
>> for ref types or will the specializer ultimately create a non-erased T
>> array for them?
>>
>
> The current functionality continues with the erasure plan.  However, I
> wouldn't mind doing better!
>