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

1 Aug 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@oracle.com>
To: "B. Blaser" <bsrbnd@gmail.com>
Cc: core-libs-dev <core-libs-dev@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@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@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@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@hotmail.ca>
To: Stuart Marks <stuart.marks@oracle.com>
Cc: "core-libs-dev@openjdk.java.net" <core-libs-dev@openjdk.java.net>
Subject: Re: 8143850: retrofit ArrayDeque to implement List
Message-ID:
  <DM5PR1601MB113260B3D990190B725D1D54A52E0@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@oracle.com>
Sent: July 31, 2018 2:40 PM
To: Alex Foster
Cc: core-libs-dev@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@oracle.com><mailto:stuart.marks@oracle.com>
Sent: July 28, 2018 8:11 PM
To: Martin Buchholz; Alex Foster
Cc: Doug Lea; core-libs-dev@openjdk.java.net<mailto:core-libs-
dev@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@hotmail.ca<mailto:alexfoster@hotmail.ca>
<mailto:alexfoster@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@reini.net>
To: Alex Foster <alexfoster@hotmail.ca>, Stuart Marks
  <stuart.marks@oracle.com>
Cc: "core-libs-dev@openjdk.java.net" <core-libs-dev@openjdk.java.net>
Subject: Re: 8143850: retrofit ArrayDeque to implement List
Message-ID: <e126a760-de69-e91f-aa21-d44c30bc81e0@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@oracle.com>
Sent: July 31, 2018 2:40 PM
To: Alex Foster
Cc: core-libs-dev@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@oracle.com><mailto:stuart.marks@oracle.com>
Sent: July 28, 2018 8:11 PM
To: Martin Buchholz; Alex Foster
Cc: Doug Lea; core-libs-dev@openjdk.java.net<mailto:core-libs-
dev@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@hotmail.ca<mailto:alexfoster@hotmail.ca>
<mailto:alexfoster@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
**********************************************

Baesken, Matthias

tags

participants (1)