8143850: retrofit ArrayDeque to implement List (original) (raw)

Peter Levart peter.levart at gmail.com
Sat Aug 4 08:11:40 UTC 2018

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