8143850: retrofit ArrayDeque to implement List

[Peter Levart]

Hi all,

On 08/04/2018 01:51 AM, Stuart Marks wrote:
> 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

I'm wondering if type inheritance here is a desired property. There are 
several past "mistakes" that don't play quite well and we have to live 
with like: Hashtable/Properties, java.util.Date/java.sql.Date | 
java.sql.Time | java.sql.Timestamp.

Creating a subclass of ArrayDeque that implements List might be a 
compatibility risk that is not much smaller than simply adding List 
interface to ArrayDeque itself. Sure if the creation/lifecycle of 
ArrayDeque[.List] instance is contained in the controlled way, the risk 
is minimized, but if the instance escapes across library boundary, it 
doesn't matter if List is implemented by a subclass or the ArrayDeque 
itself. Code using ArrayDeque type might reasonably assume there is a 
single implementation that behaves in the way it always did.

There's an example in existing Java API that allows code re-use but 
doesn't expose type inheritance: package-private AbstractStringBuilder 
with public subclasses StringBuffer and StringBuilder.

This is similar from API standpoint to Stuart's option #5, but might 
allow greater code re-use (less boilerplate as there would be no 
delegation code) and of course would be more space and time efficient.

What do you think?

Regards, Peter

>
>
> 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
>>