8143850: retrofit ArrayDeque to implement List

Roger Riggs roger.riggs at oracle.com
Tue Aug 7 20:37:48 UTC 2018


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

More information about the core-libs-dev mailing list