8143850: retrofit ArrayDeque to implement List

[Roger Riggs]

Hi,

Compare with sun.awt.util.IdentityLinkedList.java; not likely to be 
exactly what you are looking for
but it is an implementation with similar features.

$.02, Roger

On 8/4/18 4:11 AM, Peter Levart wrote:
> 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
>>>
>