On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea <d...@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.