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
