8143850: retrofit ArrayDeque to implement List
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.
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
>> OK, so the API in this webrev essentially does a combination of the
>> 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.
> 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 ....
>>> Here it is:
More information about the core-libs-dev