RFR: jsr166 jdk9 integration wave 12

[Martin Buchholz]

On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 11/18/2016 02:28 AM, Remi Forax wrote:
>
>> Martin,
>> for ArrayDeque, when you start to have methods like
>>   @SuppressWarnings("unchecked")
>>    static final <E> E elementAt(Object[] es, int i) {
>>        return (E) es[i];
>>    }
>>
>> I think it's a better idea to type the field elements as a E[] instead of
>> Object[].
>> Historically, using Object(] instead of E[] was preferred because it's a
>> kind of 'more true' at runtime,
>> but it will be less true with anyfied generics and as we can see if it
>> leads to introduce method like elementAt, using E[] will make the code more
>> readable.
>>
>>
> We always use Object[] in cases where anyfication isn't possible
> (without further code rework) because we rely on null as a distinct
> value. Elsewhere we do use E[].


I've always considered using E[] a bigger cheat than the elementAt method,
due to the expectation that if reification was ever implemented, then E[]
would simply be wrong in a ClassCastException sort of way.

I will be surprised if anyfication can be made to work on collection
classes without major rewrites.  When working with elements that are
references, there is a need to null out slots that are no longer used for
the benefit of the GC, as well as a special value to mark the slot as
free.  Sometimes logically removing an element means CASing the reference
to null.