8143850: retrofit ArrayDeque to implement List

[Stuart Marks]

Thanks, Patrick! This is very helpful.

Alex, others,

(Meta: I've been at JVMLS and the OpenJDK Committers' Workshop all week, and I'm 
on vacation next week, so I don't have much time to discuss this right now. 
However, I am interested in moving this forward.)

OK, so the API in this webrev essentially does a combination of the following:

1. Adds some List methods to ArrayDeque without having it implement List; and

2. Adds public ArrayDeque.List implementation of List as an AD subclass.

There are a variety of alternative API approaches that I think we should 
consider. Among them:

3. Add a List *view* of an ArrayDeque instance, e.g. returned by an asList() 
method. (I believe Martin has suggested this.)

4. Add a new top-level List implementation that is a subclass of ArrayDeque, 
that thus implements both List and Deque interfaces.

5. Same as 4, a top level class implementing List and Deque, but which contains 
an ArrayDeque instead of subclassing ArrayDeque.

6. Modify ArrayDeque to implement List, including changing the behavior of 
equals() and hashCode().

There are a bunch of tradeoffs among these alternatives that I don't have time 
to discuss right now, but they deserve discussion. I may also have missed some 
variations. Among the criteria for evaluation are 1) implementation sharing; 2) 
API footprint; 3) compatibility. (And also probably others.)

A couple other points:

* I'd like to set aside null support. We've been discouraging nulls in 
collections for years, so allowing null in a (conceptually) new collection 
sounds like a step in the wrong direction.

* Using an array sentinel to indicate an empty collection with default size, 
like ArrayList does, is a fine idea, but I think it complicates the discussion 
and the webrev. I'd suggest that it be factored out and considered separately.

As I've said previously, the main thing to decide is what we want the API to 
look like. A discussion of the pros and cons of the various alternatives I 
listed above (and others I might have missed) is therefore called for. I can 
discuss these further after I return, but meanwhile, if anyone has any thoughts 
in the tradeoffs here, please speak up.

Oh, and of course, thanks Alex for putting work into this proposal.

s'marks


On 7/31/18 12:21 PM, Patrick Reinhart wrote:
> Am 31.07.2018 um 21:10 schrieb Patrick Reinhart:
>> Hi Alex,
>>
>> I can do that for you ....
>>
>> -Patrick
>>
> 
> Here it is:
> 
> http://cr.openjdk.java.net/~reinhapa/reviews/8143850/webrev
> 
> -Patrick
>