8143850: retrofit ArrayDeque to implement List (original) (raw)
Stuart Marks stuart.marks at oracle.com
Fri Aug 3 23:51:14 UTC 2018
- Previous message: Long chains created by direct Buffer::slice
- Next message: 8143850: retrofit ArrayDeque to implement List
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
Adds some List methods to ArrayDeque without having it implement List; and
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:
Add a List view of an ArrayDeque instance, e.g. returned by an asList() method. (I believe Martin has suggested this.)
Add a new top-level List implementation that is a subclass of ArrayDeque, that thus implements both List and Deque interfaces.
Same as 4, a top level class implementing List and Deque, but which contains an ArrayDeque instead of subclassing ArrayDeque.
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
- Previous message: Long chains created by direct Buffer::slice
- Next message: 8143850: retrofit ArrayDeque to implement List
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]