core-libs-dev Digest, Vol 135, Issue 86

Baesken, Matthias matthias.baesken at sap.com
Wed Aug 1 06:38:38 UTC 2018


Hi Brian , I'll build it on AIX  +  in case it  builds  fine put it into our test patch queue .

Best regards , Matthias


> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 31 Jul 2018 11:47:57 -0700
> From: Brian Burkhalter <brian.burkhalter at oracle.com>
> To: "B. Blaser" <bsrbnd at gmail.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: [PING] Re: [12] (AIX) 8207744: Clean up inconsistent use of
> 	opendir/closedir versus opendir64/closedir64
> Message-ID: <944A18E9-D6E3-494D-9C94-875845507E33 at oracle.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> Does anyone have any further comments on this?
> 
> Is there anyone willing to volunteer to build and test it on AIX?
> 
> Thanks,
> 
> Brian
> 
> On Jul 30, 2018, at 1:35 PM, Brian Burkhalter <brian.burkhalter at oracle.com>
> wrote:
> 
> > Hi Bernard,
> >
> > Yes we agree. I believe I already had that change to those two files in the
> revised (.01) version of the patch which I posted on Friday:
> >
> > http://cr.openjdk.java.net/~bpb/8207744/webrev.01/index.html
> >
> > Thanks,
> >
> > Brian
> >
> > On Jul 28, 2018, at 7:10 AM, B. Blaser <bsrbnd at gmail.com> wrote:
> >
> >> In these files, only 'TimeZone_md.c' & 'OperatingSystemImpl.c' seem to
> >> be missing '#define opendir opendir64' (etc...) for AIX.
> >>
> >> So, I guess I would do (blindly) something more like the patch below.
> >>
> >> Do we agree?
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 31 Jul 2018 19:08:45 +0000
> From: Alex Foster <alexfoster at hotmail.ca>
> To: Stuart Marks <stuart.marks at oracle.com>
> Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: Re: 8143850: retrofit ArrayDeque to implement List
> Message-ID:
> 	<DM5PR1601MB113260B3D990190B725D1D54A52E0 at DM5PR1601MB
> 1132.namprd16.prod.outlook.com>
> 
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Sure, I don't mind. I would have done that myself but I don't think I have
> access to upload to cr.openjdk.java.net.
> 
> 
> Alex
> 
> ________________________________
> From: Stuart Marks <stuart.marks at oracle.com>
> Sent: July 31, 2018 2:40 PM
> To: Alex Foster
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: 8143850: retrofit ArrayDeque to implement List
> 
> 
> OK, great.
> 
> 
> It looks like a heavily modified version of ArrayDeque.java. This makes it a bit
> difficult to understand what the changes are. Would you mind if I rehosted
> this to cr.openjdk.java.net and generated a webrev for it?
> 
> 
> Thanks,
> 
> 
> s'marks
> 
> On 7/28/18 11:05 PM, Alex Foster wrote:
> 
> Hi,
> 
> 
> Here's my current proposal: https://pastebin.com/EABgwLYS
> 
> 
> Alex
> 
> 
> ________________________________
> From: Stuart Marks
> <stuart.marks at oracle.com><mailto:stuart.marks at oracle.com>
> Sent: July 28, 2018 8:11 PM
> To: Martin Buchholz; Alex Foster
> Cc: Doug Lea; core-libs-dev at openjdk.java.net<mailto:core-libs-
> dev at openjdk.java.net>
> Subject: Re: 8143850: retrofit ArrayDeque to implement List
> 
> Hi, I finally got some time to get my head around this.
> 
> Conceptually, I like the idea of a List that's stored in a circular array, like
> ArrayDeque. The best way to manifest this in the API isn't obvious though. I
> filed the bug as "retrofit ArrayDeque to implement List" but of course it
> doesn't have to be this way.
> 
> I also think we want to reuse an existing implementation as much as possible.
> There's already too much duplication between ArrayList and ArrayDeque; we
> don't
> want a third similar implementation that will need to be maintained in
> parallel.
> 
> To Martin's points:
> 
> * Adding List-like methods to ArrayDeque without it implementing List is
> indeed
> odd, but not necessarily fatal. It does seem to raise the question "Isn't there
> a better way?" though.
> 
> * I don't want to have to add null support if at all possible, for the reasons
> Martin mentioned. Also, it's an implementation and maintenance headache.
> Of
> course the implementations like ArrayList and HashMap are proof that it can
> be
> done. But each time HashMap has been enhanced significantly, there's been
> a bug
> tail where null checking was missed in certain cases.
> 
> * Growth policy. The shared null array setup for ArrayList was added when
> we
> observed that a significant number of ArrayLists are created with the default
> constructor and then never populated. Allocating the backing array lazily
> resulted in a considerable space savings. I think this would be a good idea to
> do for ArrayDeque, but this is somewhat orthogonal to the current "retrofit
> List" discussion.
> 
> * Regarding nestmates, I don't think the use of nestmates has any advantage
> or
> disadvantage over package-level access between top-level classes in the
> same
> package. I think we should decide what we want the API to look like first, and
> then figure out how to factor things so that we can get the code sharing and
> coupling that we want. We might not be forced into contorting the API in
> order
> to get better sharing/coupling, but let's wait to cross that bridge if we come
> to it.
> 
> --
> 
> Alex, I'm not sure where your current proposal stands. Have you sent an
> update
> since the head of the thread? If you had included something as an
> attachment, it
> has likely been stripped.
> 
> Thanks,
> 
> s'marks
> 
> 
> 
> 
> 
> On 7/23/18 8:46 PM, Martin Buchholz wrote:
> > (As usual, I don't have enough time to devote to this at the moment)
> >
> > I sort of like the idea of adding all of those List methods to ArrayDeque, but
> > it's __weird__ for java code to do that, and remove(int) is a problem when
> you
> > have ArrayDeque<Integer>, so it will probably end up rejected.
> >
> > ---
> >
> > Similarly, the idea of an ArrayDeque subclass that accepts nulls will be
> > unpopular - null elements have fallen out of favor.
> >
> > While|Deque|implementations are not strictly required to prohibit the
> insertion
> > of null elements, they are strongly encouraged to do so. Users of
> > any|Deque|implementations that do allow null elements are strongly
> > encouraged/not/to take advantage of the ability to insert nulls. This is so
> > because|null|is used as a special return value by various methods to
> indicate
> > that the deque is empty.
> >
> > ---
> >
> > It makes some sense for ArrayDeque's growth policy to be very similar to
> > ArrayList's - that should be done as an independent change.  Are there any
> > lessons to be learned from ArrayList's experience?  Is the world filled with
> > empty ArrayDeques that could share a common backing array?
> >
> > ---
> >
> > I do like the idea of having ArrayDeque's List-implementing subclass be a
> > nestmate of ArrayDeque, to share implementation details and to help
> discovery
> > and naming.  I'm not thrilled with reusing "List" in ArrayDeque.List but I
> don't
> > have a great alternative to suggest.
> >
> >
> > On Mon, Jul 16, 2018 at 10:36 AM, Alex Foster
> <alexfoster at hotmail.ca<mailto:alexfoster at hotmail.ca>
> > <mailto:alexfoster at hotmail.ca>> wrote:
> >
> >     Hi again,
> >
> >     I updated ArrayDeque with your last idea (adding all list methods but not
> >     implementing List) and added a subclass ArrayDeque.List which overrides
> >     equals and hashcode and implements List. There is also a subclass
> >     ArrayDeque.WithNulls that accepts null elements. ArrayDeque has
> removeAt(int
> >     index) instead of remove(index) to avoid overloading remove(Object).
> >
> >     I also added shared empty arrays similar to Arraylist, and a reallocate
> >     method which can do the same things as trimToSize and ensure capacity
> in
> >     Arraylist. It also allows you to trim to a specific capacity other than the
> >     size or skip trimming if the capacity is within a specified distance of the
> >     target capacity.
> >
> >     Also the bulk add methods call collection.toArray, then check the array
> for
> >     illegal elements, then add the array, which means that a collection could
> >     keep the array it returns from toArray and modify it from another thread
> >     after it has been checked but before it has been added which could lead
> to
> >     illegal elements being added to the ArrayDeque. We could maybe avoid
> this by
> >     cloning the array or checking the elements after adding them but I'm not
> >     sure if it's worth it...
> >
> >     What do you think?
> >
> >     I also changed the WhiteBox test a bit:
> >
> >     --- a/test/jdk/java/util/ArrayDeque/WhiteBox.java
> >     +++ b/test/jdk/java/util/ArrayDeque/WhiteBox.java
> >     @@ -88,7 +88,10 @@
> >
> >           @Test
> >           public void defaultConstructor() {
> >     -        checkCapacity(new ArrayDeque(), 16);
> >     +        ArrayDeque d = new ArrayDeque();
> >     +        d.add(new Object());
> >     +        d.clear();
> >     +        checkCapacity(d, 16);
> >           }
> >
> >           @Test
> >     @@ -131,7 +134,7 @@
> >                   if (rnd.nextBoolean()) d.add(99);
> >                   ArrayDeque clone = serialClone(d);
> >                   assertInvariants(clone);
> >     -            assertNotSame(elements(d), elements(clone));
> >     +            assertTrue(d.isEmpty() || elements(d) != elements(clone));
> >                   assertEquals(d, clone);
> >               }
> >           }
> >
> >     Alex
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 31 Jul 2018 21:10:53 +0200
> From: Patrick Reinhart <patrick at reini.net>
> To: Alex Foster <alexfoster at hotmail.ca>, Stuart Marks
> 	<stuart.marks at oracle.com>
> Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: Re: 8143850: retrofit ArrayDeque to implement List
> Message-ID: <e126a760-de69-e91f-aa21-d44c30bc81e0 at reini.net>
> Content-Type: text/plain; charset=utf-8
> 
> Hi Alex,
> 
> I can do that for you ....
> 
> -Patrick
> 
> Am 31.07.2018 um 21:08 schrieb Alex Foster:
> > Sure, I don't mind. I would have done that myself but I don't think I have
> access to upload to cr.openjdk.java.net.
> >
> >
> > Alex
> >
> > ________________________________
> > From: Stuart Marks <stuart.marks at oracle.com>
> > Sent: July 31, 2018 2:40 PM
> > To: Alex Foster
> > Cc: core-libs-dev at openjdk.java.net
> > Subject: Re: 8143850: retrofit ArrayDeque to implement List
> >
> >
> > OK, great.
> >
> >
> > It looks like a heavily modified version of ArrayDeque.java. This makes it a
> bit difficult to understand what the changes are. Would you mind if I
> rehosted this to cr.openjdk.java.net and generated a webrev for it?
> >
> >
> > Thanks,
> >
> >
> > s'marks
> >
> > On 7/28/18 11:05 PM, Alex Foster wrote:
> >
> > Hi,
> >
> >
> > Here's my current proposal: https://pastebin.com/EABgwLYS
> >
> >
> > Alex
> >
> >
> > ________________________________
> > From: Stuart Marks
> <stuart.marks at oracle.com><mailto:stuart.marks at oracle.com>
> > Sent: July 28, 2018 8:11 PM
> > To: Martin Buchholz; Alex Foster
> > Cc: Doug Lea; core-libs-dev at openjdk.java.net<mailto:core-libs-
> dev at openjdk.java.net>
> > Subject: Re: 8143850: retrofit ArrayDeque to implement List
> >
> > Hi, I finally got some time to get my head around this.
> >
> > Conceptually, I like the idea of a List that's stored in a circular array, like
> > ArrayDeque. The best way to manifest this in the API isn't obvious though. I
> > filed the bug as "retrofit ArrayDeque to implement List" but of course it
> > doesn't have to be this way.
> >
> > I also think we want to reuse an existing implementation as much as
> possible.
> > There's already too much duplication between ArrayList and ArrayDeque;
> we don't
> > want a third similar implementation that will need to be maintained in
> parallel.
> >
> > To Martin's points:
> >
> > * Adding List-like methods to ArrayDeque without it implementing List is
> indeed
> > odd, but not necessarily fatal. It does seem to raise the question "Isn't
> there
> > a better way?" though.
> >
> > * I don't want to have to add null support if at all possible, for the reasons
> > Martin mentioned. Also, it's an implementation and maintenance
> headache. Of
> > course the implementations like ArrayList and HashMap are proof that it
> can be
> > done. But each time HashMap has been enhanced significantly, there's
> been a bug
> > tail where null checking was missed in certain cases.
> >
> > * Growth policy. The shared null array setup for ArrayList was added when
> we
> > observed that a significant number of ArrayLists are created with the
> default
> > constructor and then never populated. Allocating the backing array lazily
> > resulted in a considerable space savings. I think this would be a good idea
> to
> > do for ArrayDeque, but this is somewhat orthogonal to the current "retrofit
> > List" discussion.
> >
> > * Regarding nestmates, I don't think the use of nestmates has any
> advantage or
> > disadvantage over package-level access between top-level classes in the
> same
> > package. I think we should decide what we want the API to look like first,
> and
> > then figure out how to factor things so that we can get the code sharing
> and
> > coupling that we want. We might not be forced into contorting the API in
> order
> > to get better sharing/coupling, but let's wait to cross that bridge if we come
> > to it.
> >
> > --
> >
> > Alex, I'm not sure where your current proposal stands. Have you sent an
> update
> > since the head of the thread? If you had included something as an
> attachment, it
> > has likely been stripped.
> >
> > Thanks,
> >
> > s'marks
> >
> >
> >
> >
> >
> > On 7/23/18 8:46 PM, Martin Buchholz wrote:
> >> (As usual, I don't have enough time to devote to this at the moment)
> >>
> >> I sort of like the idea of adding all of those List methods to ArrayDeque,
> but
> >> it's __weird__ for java code to do that, and remove(int) is a problem
> when you
> >> have ArrayDeque<Integer>, so it will probably end up rejected.
> >>
> >> ---
> >>
> >> Similarly, the idea of an ArrayDeque subclass that accepts nulls will be
> >> unpopular - null elements have fallen out of favor.
> >>
> >> While|Deque|implementations are not strictly required to prohibit the
> insertion
> >> of null elements, they are strongly encouraged to do so. Users of
> >> any|Deque|implementations that do allow null elements are strongly
> >> encouraged/not/to take advantage of the ability to insert nulls. This is so
> >> because|null|is used as a special return value by various methods to
> indicate
> >> that the deque is empty.
> >>
> >> ---
> >>
> >> It makes some sense for ArrayDeque's growth policy to be very similar to
> >> ArrayList's - that should be done as an independent change.  Are there
> any
> >> lessons to be learned from ArrayList's experience?  Is the world filled with
> >> empty ArrayDeques that could share a common backing array?
> >>
> >> ---
> >>
> >> I do like the idea of having ArrayDeque's List-implementing subclass be a
> >> nestmate of ArrayDeque, to share implementation details and to help
> discovery
> >> and naming.  I'm not thrilled with reusing "List" in ArrayDeque.List but I
> don't
> >> have a great alternative to suggest.
> >>
> >>
> >> On Mon, Jul 16, 2018 at 10:36 AM, Alex Foster
> <alexfoster at hotmail.ca<mailto:alexfoster at hotmail.ca>
> >> <mailto:alexfoster at hotmail.ca>> wrote:
> >>
> >>     Hi again,
> >>
> >>     I updated ArrayDeque with your last idea (adding all list methods but
> not
> >>     implementing List) and added a subclass ArrayDeque.List which
> overrides
> >>     equals and hashcode and implements List. There is also a subclass
> >>     ArrayDeque.WithNulls that accepts null elements. ArrayDeque has
> removeAt(int
> >>     index) instead of remove(index) to avoid overloading remove(Object).
> >>
> >>     I also added shared empty arrays similar to Arraylist, and a reallocate
> >>     method which can do the same things as trimToSize and ensure capacity
> in
> >>     Arraylist. It also allows you to trim to a specific capacity other than the
> >>     size or skip trimming if the capacity is within a specified distance of the
> >>     target capacity.
> >>
> >>     Also the bulk add methods call collection.toArray, then check the array
> for
> >>     illegal elements, then add the array, which means that a collection could
> >>     keep the array it returns from toArray and modify it from another
> thread
> >>     after it has been checked but before it has been added which could lead
> to
> >>     illegal elements being added to the ArrayDeque. We could maybe avoid
> this by
> >>     cloning the array or checking the elements after adding them but I'm
> not
> >>     sure if it's worth it...
> >>
> >>     What do you think?
> >>
> >>     I also changed the WhiteBox test a bit:
> >>
> >>     --- a/test/jdk/java/util/ArrayDeque/WhiteBox.java
> >>     +++ b/test/jdk/java/util/ArrayDeque/WhiteBox.java
> >>     @@ -88,7 +88,10 @@
> >>
> >>           @Test
> >>           public void defaultConstructor() {
> >>     -        checkCapacity(new ArrayDeque(), 16);
> >>     +        ArrayDeque d = new ArrayDeque();
> >>     +        d.add(new Object());
> >>     +        d.clear();
> >>     +        checkCapacity(d, 16);
> >>           }
> >>
> >>           @Test
> >>     @@ -131,7 +134,7 @@
> >>                   if (rnd.nextBoolean()) d.add(99);
> >>                   ArrayDeque clone = serialClone(d);
> >>                   assertInvariants(clone);
> >>     -            assertNotSame(elements(d), elements(clone));
> >>     +            assertTrue(d.isEmpty() || elements(d) != elements(clone));
> >>                   assertEquals(d, clone);
> >>               }
> >>           }
> >>
> >>     Alex
> >>
> >>
> 
> 
> 
> 
> End of core-libs-dev Digest, Vol 135, Issue 86
> **********************************************


More information about the core-libs-dev mailing list