From vladimir.kozlov at oracle.com  Wed Aug  1 05:04:16 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 31 Jul 2018 22:04:16 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <ecc55954-eb9c-b9fd-622a-fee8b3fbfd8f@redhat.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
 <ecc55954-eb9c-b9fd-622a-fee8b3fbfd8f@redhat.com>
Message-ID: <f057ea52-4a25-489a-cb54-40186d3b1932@oracle.com>

Hi Andrew,

I think most people are concentrating on JVMLS/OJW currently. That could explain a lack of comments.
But from the discussion on this thread I see that your proposal is well received.

On 7/31/18 4:01 AM, Andrew Dinn wrote:
> Well, given the lack of any further input I am left wondering, JEP
> neophyte that I am, whether:
> 
>    i) said happy lacuna implies that it is appropriate to submit this JEP
> (as prompted by both the process blurb provided in JEP 1 and the
> accordingly labelled button in the JEP JIRA interface)

You should look on http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html:

"The first three states for a Feature or Infrastructure JEP are:
   Draft ? Initial state in which the JEP is drafted, reviewed, revised, and endorsed
   Submitted ? By the JEP?s owner, declaring the JEP ready to be evaluated for the JDK Roadmap
   Candidate ? By the OpenJDK Lead, to add the JEP to the JDK Roadmap".

JEP needs to be reviewed and endorsed by "Group or Area Lead" before moving it to "Submitted" state.

Alan and Brian should do this from Libs side and Mikael and I from Hotspot side:
http://openjdk.java.net/projects/jdk/leads

And all of us are on JVMLS/OJW this week. Please, wait.

> 
> or
> 
>    ii) the which unfortunate hiatus in commentary indicates simply that I
> have failed to engage with the relevant worthies of this parish
> 
> Also, Iris (privately) mentioned something about "CSRs that add/modify
> public APIs in the "java.*" modules". Does that mean there is more
> paperwork to come? Now or later?

Yes, you need to file CSR in JBS but only when JEP is in later stages and API changes are finalized.

https://wiki.openjdk.java.net/display/csr/CSR+FAQs

There should be "Create CSR" in "More" menu button. It has similar to JEP format:

https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request

Regards,
Vladimir

> 
> Advice on how to progress would be very welcome.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

From matthias.baesken at sap.com  Wed Aug  1 06:38:38 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 1 Aug 2018 06:38:38 +0000
Subject: core-libs-dev Digest, Vol 135, Issue 86
In-Reply-To: <mailman.9663.1533064260.4678.core-libs-dev@openjdk.java.net>
References: <mailman.9663.1533064260.4678.core-libs-dev@openjdk.java.net>
Message-ID: <c98eb8fc62144be5b0bd33cf42503780@sap.com>


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
> **********************************************

From adinn at redhat.com  Wed Aug  1 07:41:04 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 1 Aug 2018 08:41:04 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <f057ea52-4a25-489a-cb54-40186d3b1932@oracle.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
 <ecc55954-eb9c-b9fd-622a-fee8b3fbfd8f@redhat.com>
 <f057ea52-4a25-489a-cb54-40186d3b1932@oracle.com>
Message-ID: <c3fd0362-2b61-a98d-69a3-59df82626817@redhat.com>

Hi Vladimir,

Thank you for the very helpful explanation. I will happily wait for
further feedback (Alan contacted me offline with similar advice).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From Alan.Bateman at oracle.com  Wed Aug  1 12:15:23 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Aug 2018 05:15:23 -0700
Subject: Add x-IBM-1129 charset
In-Reply-To: <OF0DCF3801.6C75FBAE-ON002582DA.00561C69-652582DA.0056CA12@notes.na.collabserv.com>
References: <OF914D21E7.1C3D5C15-ON00258292.002B6CE6-65258292.002BA833@notes.na.collabserv.com>
 <5B59FF21.8010808@oracle.com>
 <OF0DCF3801.6C75FBAE-ON002582DA.00561C69-652582DA.0056CA12@notes.na.collabserv.com>
Message-ID: <e101a353-9944-4aff-24ce-be8ea198d0e6@oracle.com>

On 30/07/2018 08:47, Nasser Ebrahim wrote:
> Thank you Sherman for reviewing the webrev and approving the changes. Can
> you please create a bug to proceed further.
>
> Regarding the other two charsets, IBM964 and IBM33722, we will analyze
> further to see whether it can be better implemented.
>
I've created JDK-8208634 [1] for x-IBM-1129 and will reply soon on the 
other thread (as I think we do need infrastructure in the build to make 
it easy to included/exclude charsets rather than having them be included 
automatically on all builds).

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8208634

From igor.ignatyev at oracle.com  Wed Aug  1 19:42:11 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 1 Aug 2018 12:42:11 -0700
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 
Message-ID: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
> 5 lines changed: 0 ins; 0 del; 5 mod;

Hi all,

could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated.

webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8208647
testing: tier1-2

Thanks,
-- Igor



From magnus.ihse.bursie at oracle.com  Wed Aug  1 20:06:44 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Aug 2018 13:06:44 -0700
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13
In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
Message-ID: <99f1666e-8db8-fc1e-58ed-80df493dc533@oracle.com>

On 2018-08-01 12:42, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
>> 5 lines changed: 0 ins; 0 del; 5 mod;
> Hi all,
>
> could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647

Build changes look good.

/Magnus
> testing: tier1-2
>
> Thanks,
> -- Igor
>
>


From vladimir.kozlov at oracle.com  Wed Aug  1 22:32:21 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 1 Aug 2018 15:32:21 -0700
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13
In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
Message-ID: <b6877409-925b-7ac4-65ee-c3cb05050e78@oracle.com>

Good.

Vladimir

On 8/1/18 12:42 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
>> 5 lines changed: 0 ins; 0 del; 5 mod;
> 
> Hi all,
> 
> could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647
> testing: tier1-2
> 
> Thanks,
> -- Igor
> 
> 

From david.holmes at oracle.com  Thu Aug  2 05:33:34 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Aug 2018 15:33:34 +1000
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13
In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
Message-ID: <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com>

Hi Igor,

On 2/08/2018 5:42 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
>> 5 lines changed: 0 ins; 0 del; 5 mod;
> 
> Hi all,
> 
> could you please review this small fix which switches jtreg to the latest available build? 

Okay.

> due to changes in javatest API, failure_handler had to be slightly updated.

Don't understand how anything in javatest affected the code you changed, 
but it's cleaner to specify its a Map<String, String> and avoid the casts.

Thanks,
David

> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647
> testing: tier1-2
> 
> Thanks,
> -- Igor
> 
> 

From igor.ignatyev at oracle.com  Thu Aug  2 05:39:11 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 1 Aug 2018 22:39:11 -0700
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13
In-Reply-To: <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com>
References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
 <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com>
Message-ID: <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com>



> On Aug 1, 2018, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Igor,
> 
> On 2/08/2018 5:42 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
>>> 5 lines changed: 0 ins; 0 del; 5 mod;
>> Hi all,
>> could you please review this small fix which switches jtreg to the latest available build? 
> 
> Okay.
> 
>> due to changes in javatest API, failure_handler had to be slightly updated.
> 
> Don't understand how anything in javatest affected the code you changed, but it's cleaner to specify its a Map<String, String> and avoid the casts.

com.sun.javatest.InterviewParameters::save used to be 'save(Map)', and now it's 'save(Map<String, String>)', so w/o changing 'map' local, we would get compile-time error.

-- Igor 
> Thanks,
> David
> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647
>> testing: tier1-2
>> Thanks,
>> -- Igor


From david.holmes at oracle.com  Thu Aug  2 06:07:31 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Aug 2018 16:07:31 +1000
Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13
In-Reply-To: <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com>
References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com>
 <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com>
 <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com>
Message-ID: <7c6d3fcf-5eb9-e65b-5d7c-589ba66c5dcd@oracle.com>

On 2/08/2018 3:39 PM, Igor Ignatyev wrote:
> 
> 
>> On Aug 1, 2018, at 10:33 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Igor,
>>
>> On 2/08/2018 5:42 AM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html
>>>> 5 lines changed: 0 ins; 0 del; 5 mod;
>>> Hi all,
>>> could you please review this small fix which switches jtreg to the latest available build?
>>
>> Okay.
>>
>>> due to changes in javatest API, failure_handler had to be slightly updated.
>>
>> Don't understand how anything in javatest affected the code you changed, but it's cleaner to specify its a Map<String, String> and avoid the casts.
> 
> com.sun.javatest.InterviewParameters::save used to be 'save(Map)', and now it's 'save(Map<String, String>)', so w/o changing 'map' local, we would get compile-time error.

Ah! Of course.

Thanks,
David

> -- Igor
>> Thanks,
>> David
>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647
>>> testing: tier1-2
>>> Thanks,
>>> -- Igor
> 

From matthias.baesken at sap.com  Thu Aug  2 12:24:00 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 2 Aug 2018 12:24:00 +0000
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
Message-ID: <e5af840807654031ab854b2fbc6714aa@sap.com>

Hi Brian ,  builds + tests  ( with your  change  included)    last night on AIX were good .

However while looking into the coding a bit more, I noticed the following :

IBM states for AIX  :

https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm

Note An open directory by opendir64 subroutine must always be closed with the closedir64 subroutine to ensure that the next attempt to open that directory is successful. In addition,
it must be operated using the 64-bit interfaces (readdir64, telldir64, seekdir64, rewinddir64, and closedir64) to obtain the correct directory information.


However this is  currently not the case everywhere  : for example I see in

http://cr.openjdk.java.net/~bpb/8207744/webrev.01/src/java.base/share/native/libjli/wildcard.c.frames.html

a readdir   (without 64).

Same for
http://cr.openjdk.java.net/~bpb/8207744/webrev.01/raw_files/new/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c



Best regards, Matthias




From: Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: Mittwoch, 1. August 2018 16:53
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: Re: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64

Hi Matthias

On Aug 1, 2018, at 3:51 AM, Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:


 [F]irst sorry for  the messed up previous  mail .
I forgot  to fix the subject and remove some parts  of the digest ? .

No worries.


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

Build was fine on AIX .
I put it into our test patch queue and  come back to your tomorrow with  some info about the tests .

Thank you very much!

Best regards,

Brian

PS I will still need an imprimatur from a JDK 12 Reviewer.

From brian.burkhalter at oracle.com  Thu Aug  2 14:59:09 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 Aug 2018 07:59:09 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <e5af840807654031ab854b2fbc6714aa@sap.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
Message-ID: <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>

Hi Matthias,

Thanks for the build + test.

I will take a look at what you observed. The whole process is a bit protracted since I cannot build and test but your assistance is appreciated.

Thanks,

Brian

On Aug 2, 2018, at 5:24 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:

> builds + tests  ( with your  change  included)    last night on AIX were good .
>  
> However while looking into the coding a bit more, I noticed the following :
>  
> IBM states for AIX  :
>  
> https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm
>  
> Note An open directory by opendir64subroutine must always be closed with theclosedir64 subroutine to ensure that the next attempt to open that directory is successful. In addition,
> it must be operated using the 64-bit interfaces (readdir64, telldir64, seekdir64,rewinddir64, and closedir64) to obtain the correct directory information.
>  
>  
> However this is  currently not the case everywhere  : for example I see in
>  
> http://cr.openjdk.java.net/~bpb/8207744/webrev.01/src/java.base/share/native/libjli/wildcard.c.frames.html
>  
> a readdir   (without 64).
>  
> Same for
> http://cr.openjdk.java.net/~bpb/8207744/webrev.01/raw_files/new/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c


From brian.burkhalter at oracle.com  Thu Aug  2 23:16:12 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 Aug 2018 16:16:12 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
Message-ID: <F2329BC0-FCAC-4117-9969-706020F8BC19@oracle.com>

Hi Matthias,

I went back through all this code and looked at the IBM documentation you sent and man pages on Linux, macOS, and Solaris trying to get some consistency. This is what I came up with:

http://cr.openjdk.java.net/~bpb/8207744/webrev.02/

It built successfully on our usual Linux, macOS, and Solaris targets. The Windows build is still running and tests on the other systems have begun. We?ll see how it turns out.

It is not unlikely that there is some historical stuff here that I am ignorant of or something specific to these functions which this change would break, so it would be good to hear from someone better versed or with some historical context. In particular the last comment in [1] by Martin (echoed in lines 105-106 of [2]) would be worth hearing about. I don?t see that the function readdir64() still even exists on Solaris.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-6339493
[2] http://cr.openjdk.java.net/~bpb/8207744/webrev.02/src/java.base/unix/native/libjava/childproc.c-.html

On Aug 2, 2018, at 7:59 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Matthias,
> 
> Thanks for the build + test.
> 
> I will take a look at what you observed. The whole process is a bit protracted since I cannot build and test but your assistance is appreciated.
> 
> Thanks,
> 
> Brian
> 
> On Aug 2, 2018, at 5:24 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> builds + tests  ( with your  change  included)    last night on AIX were good .
>> 
>> However while looking into the coding a bit more, I noticed the following :
>> 
>> IBM states for AIX  :
>> 
>> https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm
>> 
>> Note An open directory by opendir64subroutine must always be closed with theclosedir64 subroutine to ensure that the next attempt to open that directory is successful. In addition,
>> it must be operated using the 64-bit interfaces (readdir64, telldir64, seekdir64,rewinddir64, and closedir64) to obtain the correct directory information.
>> 
>> 
>> However this is  currently not the case everywhere  : for example I see in
>> 
>> http://cr.openjdk.java.net/~bpb/8207744/webrev.01/src/java.base/share/native/libjli/wildcard.c.frames.html
>> 
>> a readdir   (without 64).
>> 
>> Same for
>> http://cr.openjdk.java.net/~bpb/8207744/webrev.01/raw_files/new/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
> 


From matthias.baesken at sap.com  Fri Aug  3 06:57:59 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 3 Aug 2018 06:57:59 +0000
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
Message-ID: <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>

Hi Brian ,  looks  like the  function

struct dirent64 *readdir64 (DIR64 *DirectoryPointer);

returns   dirent64*   ( according to  https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm   )

and  some of  the files below  still have  dirent* on AIX  ( at some places it is redefined ).

For example  :

http://cr.openjdk.java.net/~bpb/8207744/webrev.02/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.frames.html

508 jint unix_getChildren(JNIEnv *env, jlong jpid, jlongArray jarray,
509                       jlongArray jparentArray, jlongArray jstimesArray) {
510     DIR* dir;
511     struct dirent* ptr;


Not sure if this is really an issue  in "real life"  ....



Best regards, Matthias



From: Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: Donnerstag, 2. August 2018 16:59
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: core-libs-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at sap.com>
Subject: Re: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64

Hi Matthias,

Thanks for the build + test.

I will take a look at what you observed. The whole process is a bit protracted since I cannot build and test but your assistance is appreciated.

Thanks,

Brian

On Aug 2, 2018, at 5:24 AM, Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:


builds + tests  ( with your  change  included)    last night on AIX were good .

However while looking into the coding a bit more, I noticed the following :

IBM states for AIX  :

https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm

Note An open directory by opendir64subroutine must always be closed with theclosedir64 subroutine to ensure that the next attempt to open that directory is successful. In addition,
it must be operated using the 64-bit interfaces (readdir64, telldir64, seekdir64,rewinddir64, and closedir64) to obtain the correct directory information.


However this is  currently not the case everywhere  : for example I see in

http://cr.openjdk.java.net/~bpb/8207744/webrev.01/src/java.base/share/native/libjli/wildcard.c.frames.html

a readdir   (without 64).

Same for
http://cr.openjdk.java.net/~bpb/8207744/webrev.01/raw_files/new/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c


From vyom.tewari at oracle.com  Fri Aug  3 07:45:25 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Fri, 3 Aug 2018 13:15:25 +0530
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
Message-ID: <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>

Hi Chris,

Overall looks good to me, couple of minor comment.

1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with 
specific? exceptions.

2-> In couple of? places we are calling "removeFromEnvironment" on 
context and spec says it will return "null" if the env is not set. I? 
see that we are setting the required env in "initContext"? so it will 
never be "null" in our tests, but i? suggest you to put just one liner 
comment that "val" can not be null. This is just to improve code 
readability, please feel free to ignore, if you think it is not worth 
enough.

Thanks,

Vyom


On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>
> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>
> Regards,
> Chris
>
>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>
>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>
>> Regards,
>> Chris


From xu.y.yin at oracle.com  Fri Aug  3 09:16:06 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 3 Aug 2018 17:16:06 +0800
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
Message-ID: <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>

Hi, Vyom

Thank a lot for your review and comments, inline and update new webrev as below

http://cr.openjdk.java.net/~xyin/8208279/webrev.02/

> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Overall looks good to me, couple of minor comment.
> 
> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.

Fixed, thanks

> 
> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.

Sure, added one line comment before each ?removeFromEnvironment? call as you suggested

Thanks,
Chris

> 
> Thanks,
> 
> Vyom
> 
> 
> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>> 
>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>> 
>> Regards,
>> Chris
>> 
>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>> 
>>> Regards,
>>> Chris
> 


From mearvk at outlook.com  Fri Aug  3 13:22:07 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 3 Aug 2018 13:22:07 +0000
Subject: System.java Development Question
Message-ID: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>

Hello.

I'm not sure if there's a minor typo but I cannot find the error in it.  Can you guys look? In System.c we have:


JNIEXPORT void JNICALL
Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla, jobject listener)
{
    jfieldID fid =   (*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;");

    if (fid == 0)
        return;

    (*env)->SetStaticObjectField(env,cla,fid,listener);
}

-- -- -- -- --

And in System.java we have:

    public static final MemoryAllocationListener memoryAllocationListener = null;


...

    public static void setMemoryAllocationListener(MemoryAllocationListener memoryAllocationListener) {
        checkMalloc();
        setMemoryAllocationListener0(memoryAllocationListener);
    }


...


    //SecureJVM private
    private static native void setMemoryAllocationListener0(MemoryAllocationListener memoryAllocationListener);


-- -- -- -- --


We get the following after running a trivial Java program:

Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
at Hope.<init>(Hope.java:19)
at Hope.main(Hope.java:11)


-- --

Can we skip right to it?  What is the issue here?

Thanks.

Max R.

From Alan.Bateman at oracle.com  Fri Aug  3 13:38:02 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Aug 2018 06:38:02 -0700
Subject: System.java Development Question
In-Reply-To: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>

On 03/08/2018 06:22, mr rupplin wrote:
> :
>
>
> We get the following after running a trivial Java program:
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
> at Hope.<init>(Hope.java:19)
> at Hope.main(Hope.java:11)
>
>
> -- --
>
> Can we skip right to it?  What is the issue here?
>
Which JDK build is this? I can't tell if it has the map files used by 
the linker (mapfile-vers in the case of libjava) or not. The map files 
don't exist in the main line but they may exist if you are working on a 
patch for a previous release.

-Alan

From mearvk at outlook.com  Fri Aug  3 13:42:26 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 3 Aug 2018 13:42:26 +0000
Subject: System.java Development Question
In-Reply-To: <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
Message-ID: <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>

This is an OpenJDK 9 build.  Can you explain?  I'm very interested in getting all the details understood.  Hey thanks!

MR
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Friday, August 3, 2018 9:38 AM
To: mr rupplin; core-libs-dev at openjdk.java.net
Subject: Re: System.java Development Question

On 03/08/2018 06:22, mr rupplin wrote:
> :
>
>
> We get the following after running a trivial Java program:
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
> at Hope.<init>(Hope.java:19)
> at Hope.main(Hope.java:11)
>
>
> -- --
>
> Can we skip right to it?  What is the issue here?
>
Which JDK build is this? I can't tell if it has the map files used by
the linker (mapfile-vers in the case of libjava) or not. The map files
don't exist in the main line but they may exist if you are working on a
patch for a previous release.

-Alan

From brian.burkhalter at oracle.com  Fri Aug  3 15:11:48 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 3 Aug 2018 08:11:48 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
Message-ID: <DDCAEAA7-09EE-40C9-B3A0-F37FDB582E61@oracle.com>

Hi Matthias,

No, I don?t know either whether this matters in reality but I will check it out. As long as I am fooling around in this area we might as well try to get it clean.


Thanks,

Brian

On Aug 2, 2018, at 11:57 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:

> Hi Brian ,  looks  like the  function
>  
> struct dirent64 *readdir64 (DIR64 *DirectoryPointer);
>  
> returns   dirent64*   ( according to https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm   )
>  
> and  some of  the files below  still have  dirent* on AIX  ( at some places it is redefined ).
>  
> For example  :
>  
> http://cr.openjdk.java.net/~bpb/8207744/webrev.02/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.frames.html
>  
> 508 jint unix_getChildren(JNIEnv *env, jlong jpid, jlongArray jarray,
> 509                       jlongArray jparentArray, jlongArray jstimesArray) {
> 510     DIR* dir;
> 511     struct dirent* ptr;
>  
>  
> Not sure if this is really an issue  in ?real life?  ?.


From enasser at in.ibm.com  Fri Aug  3 15:33:30 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Fri, 3 Aug 2018 21:03:30 +0530
Subject: Add x-IBM-1129 charset
In-Reply-To: <e101a353-9944-4aff-24ce-be8ea198d0e6@oracle.com>
References: <OF914D21E7.1C3D5C15-ON00258292.002B6CE6-65258292.002BA833@notes.na.collabserv.com>
 <5B59FF21.8010808@oracle.com>
 <OF0DCF3801.6C75FBAE-ON002582DA.00561C69-652582DA.0056CA12@notes.na.collabserv.com>
 <e101a353-9944-4aff-24ce-be8ea198d0e6@oracle.com>
Message-ID: <OFACE89864.2077F584-ON002582DE.00546C85-652582DE.005576A1@notes.na.collabserv.com>

> I've created JDK-8208634 [1] for x-IBM-1129 and will reply soon on the 
> other thread (as I think we do need infrastructure in the build to make 
> it easy to included/exclude charsets rather than having them be included 

> automatically on all builds).

Thank you Alan for opening the bug for this issue. 
I will wait for your response on the other thread and proceed as per your 
inputs.

Regards,
Nasser Ebrahim




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Nasser Ebrahim <enasser at in.ibm.com>, Xueming Shen 
<xueming.shen at oracle.com>, core-libs-dev at openjdk.java.net
Date:   08/01/2018 05:45 PM
Subject:        Re: Add x-IBM-1129 charset



On 30/07/2018 08:47, Nasser Ebrahim wrote:
> Thank you Sherman for reviewing the webrev and approving the changes. 
Can
> you please create a bug to proceed further.
>
> Regarding the other two charsets, IBM964 and IBM33722, we will analyze
> further to see whether it can be better implemented.
>
I've created JDK-8208634 [1] for x-IBM-1129 and will reply soon on the 
other thread (as I think we do need infrastructure in the build to make 
it easy to included/exclude charsets rather than having them be included 
automatically on all builds).

-Alan

[1] 
https://bugs.openjdk.java.net/browse/JDK-8208634







From adinn at redhat.com  Fri Aug  3 15:44:03 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 3 Aug 2018 16:44:03 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
Message-ID: <ff4a77c3-3f7d-87a2-5d2b-8729406c168c@redhat.com>

Round 3:

This week Jonathan Halliday was able to access a machine which has both
an NVM DIMM and CPU that implements the clflush and clwb instructions.
He is currently preparing some benchmark figures for running
transactions using a log stored in NVM. However, in order to get to that
point we had to exercise and then fixed a few things that were
unexercised on DRAM/CPU without clflush and clwb.

So, here is a new webrev which fixes the errors found in the previous drop:

  New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.03

The changes are all fairly trivial:

MappedByteBuffer.java
 - fixed a copy-paste error which meant force(from to) was passing an
incorrect address range length

vm_version_x86.hpp
 - corrected an error in the bitwise tests that detect presence of hw
flush insns

assembler_x86.cpp
  - ensured a register prefix is generated when the address is encoded
in register r8 and upwards

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From enasser at in.ibm.com  Fri Aug  3 17:09:35 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Fri, 3 Aug 2018 22:39:35 +0530
Subject: RFR: JDK-8208634 : Add x-IBM-1129 charset
Message-ID: <OF62BE1575.E1F80DDC-ON002582DE.00557E08-652582DE.005E42D1@notes.na.collabserv.com>

Hello,

Java was not launching on many AIX supported locales as the default 
charsets for those locales were not included in the java.base and Java 
could not access jdk.charsets during boot up. 

Most of those locales were addressed through the Oracle bugs JDK-8201540 
[1] and  JDK-8202329 [2]. Still, few more are pending. In the remaining 
locales, two charsets (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are missing in 
the jdk.charsets as well.

In this enhancement, IBM-1129 charset is getting added to jdk.charsets on 
all platforms and to java.base on AIX platform.

The webrev of the fix is available at
http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/

Kindly request you to review the webrev and provide your comments.

[1] https://bugs.openjdk.java.net/browse/JDK-8201540
[2] https://bugs.openjdk.java.net/browse/JDK-8202329

Thank you,
Nasser Ebrahim


From rednaxelafx at gmail.com  Fri Aug  3 18:34:11 2018
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Fri, 3 Aug 2018 11:34:11 -0700
Subject: Race condition when serializing SerializedRandomAccessList
Message-ID: <CA+cQ+tSQBj1qQqSUhLwiUhWNUAyjisLsAO1tZeFVf=ULnJbmJw@mail.gmail.com>

Hi core-libs,

I'd like to report a bug on race condition while serializing
SerializedRandomAccessList / deserializing SerializedList. This seems to be
a long standing bug, we've hit it on JDK8 and the same code is still there
in JDK11's core-lib.

In SerializedRandomAccessList.writeReplace(): [1]

        private Object writeReplace() {
            return new SynchronizedList<>(list);
        }

Here, it's creating a new "face" of the current SerializedRandomAccessList,
but not passing down this.mutex into the newly created SynchronizedList.
What we've seen go wrong was that one thread was still appending to the
SerializedRandomAccessList, while another thread is trying to serialize it,
a ConcurrentModificationException may be thrown on the underlying list.

I've filed JDK-8208779 [2] to track this issue.

Note: this issue was reported by my colleague Shixiong Zhu at Databricks.
I'm just delegating the report to the core-libs list.
One past occurrence of the same issue can be found in Apache Spark in [3].

Thanks,
Kris

[1]:
http://hg.openjdk.java.net/jdk/jdk11/file/4322ef0c1684/src/java.base/share/classes/java/util/Collections.java#l2521
[2]: https://bugs.openjdk.java.net/browse/JDK-8208779
[3]:
https://issues.apache.org/jira/browse/SPARK-17463?focusedCommentId=15787809&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15787809

From calvin.cheung at oracle.com  Fri Aug  3 18:37:37 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 03 Aug 2018 11:37:37 -0700
Subject: RFR: 8207263: Store the Configuration for system modules into
 CDS archive
In-Reply-To: <cca4f157-6c88-2931-f012-4daff7205dc1@oracle.com>
References: <cca4f157-6c88-2931-f012-4daff7205dc1@oracle.com>
Message-ID: <5B64A0F1.9060302@oracle.com>

Hi Jiangli,

The changes look good to me.

I have couple of minor comments:

1) vmSymbols.hpp

  653   template(url_void_signature,                     
"(Ljava/net/URL;)V")                                           \
  654   template(toFileURL_name,                         
"toFileURL")                                                   \
  655   template(toFileURL_signature,                    
"(Ljava/lang/String;)Ljava/net/URL;")

Since you've moved the above lines to after 
?template(systemModules_signature, ??, I?d suggest rearrange the entire 
block (lines 652 - 659) in alphabetical order.

2) CheckArchivedModuleApp.java

Since it now expects two input args, I?d suggest checking the number of 
input args and throw an exception if it is not equal to two.

thanks,
Calvin

On 7/20/18, 11:31 AM, Jiangli Zhou wrote:
> Please review the following webrev that archives the system module 
> boot layer Configuration (including all java objects reachable from 
> the Configuration) in CDS archive. This is built on top of the earlier 
> change for JDK-8202035 
> (https://bugs.openjdk.java.net/browse/JDK-8202035), which provides a 
> framework for object sub-graph archiving.
>
> The boot layer Configuration is created in ModuleBootstrap.boot() 
> (similar to the archived system ModuleDescriptor objects, etc) and is 
> unchanged after construction. With archived boot layer Configuration, 
> it allows runtime to bypass the work for creating the configuration. 
> Currently, this is only supported when the initial module is unnamed 
> module. Measurements indicate archiving the boot layer Configuration 
> improves the startup time by 1% ~ 1.5% (on linux-x64) when running 
> HelloWorld from -cp at runtime.
>
> Many thanks to Alan and Claes for discussions and contributions to 
> this change!
>
> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8207263
>
> Tested with tier1 - tier5 tests via mach5.
>
> Thanks,
>
> Jiangli
>

From joe.darcy at oracle.com  Fri Aug  3 21:47:58 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 03 Aug 2018 14:47:58 -0700
Subject: JDK 12 RFR of JDK-8208782: Remove extra type in throws clause of
 SerialClob.writeObject
Message-ID: <5B64CD8E.3010509@oracle.com>

Hello,

The fix for JDK-8208060, Additional corrections of serial-related 
declarations, overlooked an extra type in the throws clause of 
javax.sql.rowset.serial.SerialClob.writeObject. The extra type should be 
removed.

Patch below.

Thanks,

-Joe

--- 
old/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 
2018-08-03 14:45:17.977105996 -0700
+++ 
new/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 
2018-08-03 14:45:17.453105982 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -663,7 +663,7 @@
       * to a stream.
       */
      private void writeObject(ObjectOutputStream s)
-            throws IOException, ClassNotFoundException {
+            throws IOException {

          ObjectOutputStream.PutField fields = s.putFields();
          fields.put("buf", buf);


From lance.andersen at oracle.com  Fri Aug  3 21:52:02 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 3 Aug 2018 17:52:02 -0400
Subject: JDK 12 RFR of JDK-8208782: Remove extra type in throws clause of
 SerialClob.writeObject
In-Reply-To: <5B64CD8E.3010509@oracle.com>
References: <5B64CD8E.3010509@oracle.com>
Message-ID: <B16A3FAE-EBED-4328-8F00-E358323DA9ED@oracle.com>

Hi Joe,

Looks fine.  Sorry I missed it also

Best
Lance
> On Aug 3, 2018, at 5:47 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The fix for JDK-8208060, Additional corrections of serial-related declarations, overlooked an extra type in the throws clause of javax.sql.rowset.serial.SerialClob.writeObject. The extra type should be removed.
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 2018-08-03 14:45:17.977105996 -0700
> +++ new/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 2018-08-03 14:45:17.453105982 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -663,7 +663,7 @@
>      * to a stream.
>      */
>     private void writeObject(ObjectOutputStream s)
> -            throws IOException, ClassNotFoundException {
> +            throws IOException {
> 
>         ObjectOutputStream.PutField fields = s.putFields();
>         fields.put("buf", buf);
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Fri Aug  3 22:08:25 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 3 Aug 2018 15:08:25 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
Message-ID: <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>

HI Matthias,

I think I fixed the dirent problem: thanks for pointing it out.

http://cr.openjdk.java.net/~bpb/8207744/webrev.03/

The usual builds passed and tests are running.

I think that there is some _ALLBSD_SOURCE cruft in UnixNativeDispatcher.c which could be cleaned up but we?ll leave that for another day.

Thanks,

Brian

On Aug 2, 2018, at 11:57 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:

> looks  like the  function
>  
> struct dirent64 *readdir64 (DIR64 *DirectoryPointer);
>  
> returns   dirent64*   ( according to https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm   )
>  
> and  some of  the files below  still have  dirent* on AIX  ( at some places it is redefined ).
>  
> For example  :
>  
> http://cr.openjdk.java.net/~bpb/8207744/webrev.02/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.frames.html
>  
> 508 jint unix_getChildren(JNIEnv *env, jlong jpid, jlongArray jarray,
> 509                       jlongArray jparentArray, jlongArray jstimesArray) {
> 510     DIR* dir;
> 511     struct dirent* ptr;
>  
>  
> Not sure if this is really an issue  in ?real life?  ?.


From paul.sandoz at oracle.com  Fri Aug  3 22:15:30 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Aug 2018 15:15:30 -0700
Subject: Long chains created by direct Buffer::slice
In-Reply-To: <04231173-6899-4A4E-BF91-2ACA9AC6B5D4@oracle.com>
References: <87o9f1n653.fsf@mid.deneb.enyo.de>
 <20180720111559.849741094@eggemoggin.niobe.net>
 <029E054A-7238-4271-AAC5-7904E86DB3D6@oracle.com>
 <87tvolksln.fsf@mid.deneb.enyo.de>
 <04231173-6899-4A4E-BF91-2ACA9AC6B5D4@oracle.com>
Message-ID: <D1ED57AF-60C8-458E-92CB-1F4EDC0BB2A3@oracle.com>

Got caught up with JVMLS this week?

I searched but could not find a test, so i added one, see:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/>

Paul.

> On Jul 27, 2018, at 12:35 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> 
> 
>> On Jul 27, 2018, at 1:09 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> * Paul Sandoz:
>> 
>>> I created this issue:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8208362
>> 
>> Thanks.
>> 
>>> The suggested fix requires a tweak though since an instance of a
>>> DirectBuffer interface is passed. This is required because views
>>> over direct ByteBuffers can be created.
>> 
>> Noticed that as well.
>> 
>>> diff -r 448cd909c9e2 src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
>>> --- a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template	Thu Jul 26 11:53:59 2018 -0700
>>> +++ b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template	Thu Jul 26 16:46:20 2018 -0700
>>> @@ -194,7 +194,8 @@
>>> #if[byte]
>>>        cleaner = null;
>>> #end[byte]
>>> -        att = db;
>>> +        Object attachment = db.attachment();
>>> +        att = (attachment == null ? db : attachment);
>> 
>> This is essentially what I put through jtreg (jdk_core), without any
>> obvious issues,
> 
> Thanks for testing.
> 
> 
>> but I had not time yet to file a bug and create a
>> webrev.
> 
> Ah, my apologies, i did not realize you had author status.
> 
> 
>> 
>> The parenthesis seem unnecessary.  If this is an official JDK coding
>> style, it is not widely used.
> 
> 
> It is unusual but I chose to keep consistent with the style in the source.
> 
> Paul.


From stuart.marks at oracle.com  Fri Aug  3 23:51:14 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 3 Aug 2018 16:51:14 -0700
Subject: 8143850: retrofit ArrayDeque to implement List
In-Reply-To: <7e10860f-2619-df70-4fdb-7dbc60a429ee@reini.net>
References: <CY4PR1601MB1125DCD8F9281E6BDB3CFDCAA5490@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe08vZcjtXkxmWkhBkH8FJc81kBX-hs-t1rC_yHbDivDHkg@mail.gmail.com>
 <CY4PR1601MB1125C26A587B2B4772C7B29AA54E0@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe0-jfxRvT1xULDKNDAB8FUjMXybaBL_K1AUCdvsc622M=w@mail.gmail.com>
 <DM5PR1601MB1132AAE82717D7EA1757879CA5450@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <CA+kOe08BUp=f=K1koQUNd1UbK9Jjigj+aDKF_HFYHhV3+exGGw@mail.gmail.com>
 <b1d84218-e591-ba78-f602-7a6f472d58ff@oracle.com>
 <CY4PR1601MB1125ECAD1EA5D442339DB5B2A5280@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <6f2ec600-288f-8cea-9ba9-4748c3e8ad5d@oracle.com>
 <DM5PR1601MB113260B3D990190B725D1D54A52E0@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <e126a760-de69-e91f-aa21-d44c30bc81e0@reini.net>
 <7e10860f-2619-df70-4fdb-7dbc60a429ee@reini.net>
Message-ID: <5fd3e7c3-a0a2-fbe5-79bc-f9e5676466b4@oracle.com>

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


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
> 

From peter.levart at gmail.com  Sat Aug  4 08:11:40 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 4 Aug 2018 10:11:40 +0200
Subject: 8143850: retrofit ArrayDeque to implement List
In-Reply-To: <5fd3e7c3-a0a2-fbe5-79bc-f9e5676466b4@oracle.com>
References: <CY4PR1601MB1125DCD8F9281E6BDB3CFDCAA5490@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe08vZcjtXkxmWkhBkH8FJc81kBX-hs-t1rC_yHbDivDHkg@mail.gmail.com>
 <CY4PR1601MB1125C26A587B2B4772C7B29AA54E0@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe0-jfxRvT1xULDKNDAB8FUjMXybaBL_K1AUCdvsc622M=w@mail.gmail.com>
 <DM5PR1601MB1132AAE82717D7EA1757879CA5450@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <CA+kOe08BUp=f=K1koQUNd1UbK9Jjigj+aDKF_HFYHhV3+exGGw@mail.gmail.com>
 <b1d84218-e591-ba78-f602-7a6f472d58ff@oracle.com>
 <CY4PR1601MB1125ECAD1EA5D442339DB5B2A5280@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <6f2ec600-288f-8cea-9ba9-4748c3e8ad5d@oracle.com>
 <DM5PR1601MB113260B3D990190B725D1D54A52E0@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <e126a760-de69-e91f-aa21-d44c30bc81e0@reini.net>
 <7e10860f-2619-df70-4fdb-7dbc60a429ee@reini.net>
 <5fd3e7c3-a0a2-fbe5-79bc-f9e5676466b4@oracle.com>
Message-ID: <f58d02a0-550e-0f3b-fe0c-e435bb6aa40b@gmail.com>

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
>>


From mearvk at outlook.com  Sat Aug  4 12:29:27 2018
From: mearvk at outlook.com (mr rupplin)
Date: Sat, 4 Aug 2018 12:29:27 +0000
Subject: System.java Development Question
In-Reply-To: <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>,
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>

Any help?

________________________________
From: mr rupplin <mearvk at outlook.com>
Sent: Friday, August 3, 2018 9:42:26 AM
To: Alan Bateman; core-libs-dev at openjdk.java.net
Subject: Re: System.java Development Question

This is an OpenJDK 9 build.  Can you explain?  I'm very interested in getting all the details understood.  Hey thanks!

MR
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Friday, August 3, 2018 9:38 AM
To: mr rupplin; core-libs-dev at openjdk.java.net
Subject: Re: System.java Development Question

On 03/08/2018 06:22, mr rupplin wrote:
> :
>
>
> We get the following after running a trivial Java program:
>
> Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
> at Hope.<init>(Hope.java:19)
> at Hope.main(Hope.java:11)
>
>
> -- --
>
> Can we skip right to it?  What is the issue here?
>
Which JDK build is this? I can't tell if it has the map files used by
the linker (mapfile-vers in the case of libjava) or not. The map files
don't exist in the main line but they may exist if you are working on a
patch for a previous release.

-Alan

From christoph.dreis at freenet.de  Sun Aug  5 08:28:16 2018
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Sun, 5 Aug 2018 10:28:16 +0200
Subject: [NEW BUG] Fix "moduel" typo in ModuleInfo
Message-ID: <005101d42c96$42158490$c6408db0$@freenet.de>

Hi,

I just noticed this trivial typo while looking through the module related
code.

I'd be happy if this patch is accepted.

Cheers,
Christoph


=== PATCH ===
diff --git a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
--- a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
+++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
@@ -233,7 +233,7 @@
         Set<String> allPackages = null;
         String mainClass = null;
         ModuleTarget moduleTarget = null;
-        ModuleHashes moduelHashes = null;
+        ModuleHashes moduleHashes = null;
         ModuleResolution moduleResolution = null;

         for (int i = 0; i < attributes_count ; i++) {
@@ -267,7 +267,7 @@

                 case MODULE_HASHES :
                     if (parseHashes) {
-                        moduelHashes = readModuleHashesAttribute(in,
cpool);
+                        moduleHashes = readModuleHashesAttribute(in,
cpool);
                     } else {
                         in.skipBytes(length);
                     }
@@ -331,7 +331,7 @@
         ModuleDescriptor descriptor = builder.build();
         return new Attributes(descriptor,
                               moduleTarget,
-                              moduelHashes,
+                              moduleHashes,
                               moduleResolution);
     }


From Alan.Bateman at oracle.com  Sun Aug  5 18:08:04 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Aug 2018 19:08:04 +0100
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
Message-ID: <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>

On 03/08/2018 20:26, ted at tedneward.com wrote:
> Hey, all; did this get resolved? I'm still getting this error in
> pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer not to
> make local changes (mostly I want to build debug builds so I can spelunk the
> JVM bits), but if this isn't going to roll out fairly shortly I'll disable
> warnings-as-errors and carry on.
>
The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in jdk/jdk 
for JDK 12. There are few residual issues/inconsistencies that came up 
and are still under discussion on the mailing lists. I don't think there 
has been any discussion yet about back porting.

-Alan

From Alan.Bateman at oracle.com  Sun Aug  5 18:19:31 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Aug 2018 19:19:31 +0100
Subject: [NEW BUG] Fix "moduel" typo in ModuleInfo
In-Reply-To: <005101d42c96$42158490$c6408db0$@freenet.de>
References: <005101d42c96$42158490$c6408db0$@freenet.de>
Message-ID: <2969d797-9412-d796-3133-fe5d1b444b78@oracle.com>



On 05/08/2018 09:28, Christoph Dreis wrote:
> Hi,
>
> I just noticed this trivial typo while looking through the module related
> code.
>
> I'd be happy if this patch is accepted.
>
Thanks, it should be renamed. I've reviewed and sponsored the change so 
it's in jdk/jdk now.

-Alan

From Alan.Bateman at oracle.com  Sun Aug  5 18:38:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Aug 2018 19:38:45 +0100
Subject: Adding new IBM extended charsets
In-Reply-To: <OF18BC0820.BD754056-ON002582D4.002FE70C-652582D4.00312604@notes.na.collabserv.com>
References: <OF20780B57.BDD380EA-ON002582C0.0044EDAF-652582C0.0045C303@notes.na.collabserv.com>
 <5B3E4AC8.3070307@oracle.com>
 <OF5ED40FB3.D5317855-ON002582C2.00450370-652582C2.004C8D87@notes.na.collabserv.com>
 <4cba7633-33b7-f29a-fb34-05a06b224057@oracle.com>
 <OF63E18FCB.2749C189-ON002582CD.0041A2BD-652582CD.004BCE3C@notes.na.collabserv.com>
 <5B503D69.6010004@oracle.com>
 <4ed347e6-1e64-5ef6-be48-8d12b0adac6f@oracle.com>
 <OF18BC0820.BD754056-ON002582D4.002FE70C-652582D4.00312604@notes.na.collabserv.com>
Message-ID: <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>

On 24/07/2018 09:56, Nasser Ebrahim wrote:
> Thank you Martin, Sherman and Alan for your valuable inputs.
>
> I have done some initial analysis on the ICU4J. There are some 
> compatibility issues on the ICU4J charsets with JDK charsets but am 
> more concerned about its performance as JDK optimization do no exist 
> in that implementation. I think we need to work with the ICU4J 
> community to resolve those issues before we remove those charsets from 
> JDK.
If you can work with the ICU4J project on these issues then I think we 
have a way forward. An additional issue with their downloads is that 
they target JDK 6 and don't seem to have thought about deploying as 
modules with JDK 9 or newer yet. Their downloads can be used as 
automatic modules but it requires renaming their JAR files due to 
unusual naming that they use to encode the version string. A simple 
Automatic-Module-Name attribute would make it easy for developers to 
deploy their charset provider on the module path, they can still target 
JDK 6.

As regards the way forward then I think we have to put infrastructure 
into the build to make it easy to allow specific charsets be included or 
excluded from specific platforms. As things stand, and as have you have 
found with your updates to the stdcs-<platform> files, the charsets are 
generated to be included in either java.base or jdk.charsets. We need 
another input to the configurability to make it possible to include or 
exclude so that the main stream platforms do not have to include the IBM 
charsets. There are several details around this, particularly around 
aliases, but if we can get that done then we have a lot of flexibility.? 
My personal view is that we should work towards excluding the IBM 
charsets from the main stream platforms, starting with a cull of the 
EBCDIC charsets. If the ICU4J project can get their issues sorted out in 
a similar time frame then it makes for a simple migration story -- the 
JDK includes the standard charsets and many additional charsets. If you 
need others then download the ICU4J charset provider and deploy it on 
your class path or module path.

-Alan

From Alan.Bateman at oracle.com  Sun Aug  5 18:59:59 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Aug 2018 19:59:59 +0100
Subject: Long chains created by direct Buffer::slice
In-Reply-To: <D1ED57AF-60C8-458E-92CB-1F4EDC0BB2A3@oracle.com>
References: <87o9f1n653.fsf@mid.deneb.enyo.de>
 <20180720111559.849741094@eggemoggin.niobe.net>
 <029E054A-7238-4271-AAC5-7904E86DB3D6@oracle.com>
 <87tvolksln.fsf@mid.deneb.enyo.de>
 <04231173-6899-4A4E-BF91-2ACA9AC6B5D4@oracle.com>
 <D1ED57AF-60C8-458E-92CB-1F4EDC0BB2A3@oracle.com>
Message-ID: <a4047597-9e1b-8384-0f45-1d7155323efc@oracle.com>

On 03/08/2018 23:15, Paul Sandoz wrote:
> Got caught up with JVMLS this week?
>
> I searched but could not find a test, so i added one, see:
>
>    http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/>
>
One comment on the test is that the references to the intermediate refs 
may not be cleared immediately after the GC. It might be more reliable 
to loop, with a backoff, until at least one has been cleared.

-Alan

From david.holmes at oracle.com  Sun Aug  5 23:53:51 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Aug 2018 09:53:51 +1000
Subject: System.java Development Question
In-Reply-To: <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <15b462a4-4d9d-8e13-2100-480e3c799ce6@oracle.com>

On 4/08/2018 10:29 PM, mr rupplin wrote:
> Any help?

Patience is a virtue. ;-)

As Alan indicated in older releases, like 9, there is a mapfile used to 
tell the linker about exported entry points to native libraries. As you 
are using OpenJDK 9 you will need to add the appropriate entry in

jdk/make/mapfiles/libjava/mapfile-vers

David
-----

> ________________________________
> From: mr rupplin <mearvk at outlook.com>
> Sent: Friday, August 3, 2018 9:42:26 AM
> To: Alan Bateman; core-libs-dev at openjdk.java.net
> Subject: Re: System.java Development Question
> 
> This is an OpenJDK 9 build.  Can you explain?  I'm very interested in getting all the details understood.  Hey thanks!
> 
> MR
> ________________________________
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Friday, August 3, 2018 9:38 AM
> To: mr rupplin; core-libs-dev at openjdk.java.net
> Subject: Re: System.java Development Question
> 
> On 03/08/2018 06:22, mr rupplin wrote:
>> :
>>
>>
>> We get the following after running a trivial Java program:
>>
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
>> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
>> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
>> at Hope.<init>(Hope.java:19)
>> at Hope.main(Hope.java:11)
>>
>>
>> -- --
>>
>> Can we skip right to it?  What is the issue here?
>>
> Which JDK build is this? I can't tell if it has the map files used by
> the linker (mapfile-vers in the case of libjava) or not. The map files
> don't exist in the main line but they may exist if you are working on a
> patch for a previous release.
> 
> -Alan
> 

From vyom.tewari at oracle.com  Mon Aug  6 06:02:29 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Mon, 6 Aug 2018 11:32:29 +0530
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
Message-ID: <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>

Hi Chris,

Latest webrev looks good to me.

Thanks,

Vyom


On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
> Hi, Vyom
>
> Thank a lot for your review and comments, inline and update new webrev as below
>
> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/
>
>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Overall looks good to me, couple of minor comment.
>>
>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
> Fixed, thanks
>
>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>
> Thanks,
> Chris
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>
>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>
>>> Regards,
>>> Chris
>>>
>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>
>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>
>>>> Regards,
>>>> Chris


From claes.redestad at oracle.com  Mon Aug  6 06:12:35 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 6 Aug 2018 08:12:35 +0200
Subject: System.java Development Question
In-Reply-To: <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <c930a283-43c5-b5bb-11d4-a1e822ae4788@oracle.com>

On 2018-08-04 14:29, mr rupplin wrote:
> Any help?

I think it would help if you described what you're trying to achieve, 
rather than the current stumbling block.[0]

Reading between the lines then it seems you're trying to add some kind 
of adhoc allocation profiling, so I wonder if you've seen the Low 
Overhead Heap-Profiling work that went into jdk/jdk just a few weeks 
ago?[1]

If it doesn't fit your use-case - or you really need something like it 
applied to JDK 9 - it might still be good advice to study the code and 
approach taken there before reverse-engineering the entire OpenJDK 
source code... :-)

/Claes

[0] https://en.wikipedia.org/wiki/XY_problem
[1] Initial implementation: 
http://hg.openjdk.java.net/jdk/jdk/rev/e2a7f431f65c
Impl RFE: https://bugs.openjdk.java.net/browse/JDK-8203394
JEP: https://bugs.openjdk.java.net/browse/JDK-8203394

(See the JEP for follow-up bug fixes you'd need to consider if you'd 
ever attempt to backport this)

From xu.y.yin at oracle.com  Mon Aug  6 07:09:40 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Mon, 6 Aug 2018 15:09:40 +0800
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
 <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
Message-ID: <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>

Thank you, Vyom

Regards,
Chris

> On 6 Aug 2018, at 2:02 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Latest webrev looks good to me.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
>> Hi, Vyom
>> 
>> Thank a lot for your review and comments, inline and update new webrev as below
>> 
>> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/
>> 
>>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Overall looks good to me, couple of minor comment.
>>> 
>>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
>> Fixed, thanks
>> 
>>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
>> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>> 
>> Thanks,
>> Chris
>> 
>>> Thanks,
>>> 
>>> Vyom
>>> 
>>> 
>>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>> 
>>>> Regards,
>>>> Chris
>>>> 
>>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>> 
>>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>> 
>>>>> Regards,
>>>>> Chris
> 


From vyom.tewari at oracle.com  Mon Aug  6 08:12:29 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Mon, 6 Aug 2018 13:42:29 +0530
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
Message-ID: <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>

Hi Chris,

1-> DirAFactory.java, "getIbjectInstance" returns "null"? if it fails to 
construct object. I will suggest you to throw? some "RuntimeException" 
instead returning null. If you return null then caller of 
"getObjectInstance" had to check for null and it will end in lots of 
boilerplate code.

2-> DirTxtFactory.java same as "DirFactory.java".

3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant 
for "1.2.4.1" and put one liner comment if possible. This is will help 
future maintainer to understand why we are comparing with this value.

One generic comment, in most of the places i can see, you declared 
functions to throw generic exception "Exception",? please change it to 
specific? exception or list of specific exceptions if possible.

Thanks,

Vyom


On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>
> Regards,
> Chris


From sgehwolf at redhat.com  Mon Aug  6 08:45:32 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 06 Aug 2018 10:45:32 +0200
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <00e901d42d5f$fea5d190$fbf174b0$@tedneward.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
 <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>
 <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <00e901d42d5f$fea5d190$fbf174b0$@tedneward.com>
Message-ID: <f00aec93c61373f3170e8bb0373da125fc5f4ebd.camel@redhat.com>

On Mon, 2018-08-06 at 01:32 -0700, ted at tedneward.com wrote:
> I'd really like to be able to build 8 and 9; particularly 8, since
> that's what my current employer is still using. :-)

For JDK 8 we have to use:

$ bash configure ...
$ make WARNINGS_ARE_ERRORS="" \
      SCTP_WERROR= \
      ...

JDK 9+ have --disable-warnings-as-errors configure option.

Thanks,
Severin


From Alan.Bateman at oracle.com  Mon Aug  6 09:29:13 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Aug 2018 10:29:13 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
Message-ID: <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>

On 25/07/2018 12:44, Andrew Dinn wrote:
> Round 2
> -------
> I have updated the JEP and uploaded a revised webrev in the light of
> existing feedback
>
>    JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
>
>    Formatted JEP: http://openjdk.java.net/jeps/8207851
>
>    New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.02/
>
> I would welcome any further comments (I guess I'd be happy to push this
> as is but I find it hard to believe it does not require more work.
> Someone must have something to add :-)
>
I read through the draft JEP and also skimmed the latest webrev.

The current iteration, to introduce new MapMode values, is not too bad 
but it makes me wonder if we could avoid new modes altogether by 
detecting that the file is backed by NVM. Is there a fcntl cmd or some 
other syscall that can be used to detect this? I'm asking because it 
would open the potential to discuss limiting the API changes to just 
MappedByteBuffer.

In the draft JEP then the Summary, Goals, Non-Goals, Success Metrics, 
and Motivation sections read well. The Description section is very wordy 
and includes a lot of implementation detail that I assume will be 
removed before it is submitted (my guess is that it can be distilled 
down to a couple of paragraphs). As a comparison, the API surface in JEP 
337 is much larger but we were able to reduce the text down to a few 
paragraphs. The Testing sectioning highlights the challenges and reminds 
me that we have several features that will need maintainers to 
continuously test to ensure that a feature doesn't bit rot (SCTP and the 
proposed APIs for RDMA sockets are in the same boat).

Are you familiar with BufferPoolMXBean which can be used by management 
tools to monitor pool of buffers? I'm wondering if we should introduce a 
new pool for NVM so that it doesn't show up in the "mapped" pool.

I can't tell from this thread if you are looking for detailed feedback 
on the current patch. A couple of random things:
- there are residual references to map_persistent in several places
- MappedByteBuffer.force will need to specify IAE
- The new methods are missing @since
- I think it would be clearer if MappedByteBuffer.force use "region" 
rather than "sub-region" as it is used in the context of the buffer, not 
the original file.
- There will be round of clean up needed to the changes to java.base to 
get the javadoc and code consistent with the javadoc/code in this area. 
I assume we'll get back to that when the patch is closer to review.

-Alan.

From xu.y.yin at oracle.com  Mon Aug  6 09:32:02 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Mon, 6 Aug 2018 17:32:02 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
Message-ID: <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>

Hi, Vyom

Many thanks for your review and comments, inline and updated webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208483/webrev.01/

> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.

?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks

Paste a few javadoc here against ?getObjectInstance? method as below

* @return The object created; null if an object cannot be created.
* @exception Exception If this object factory encountered an exception
* while attempting to create an object, and no other object factories are
* to be tried.

> 
> 2-> DirTxtFactory.java same as "DirFactory.java?.

Same as above

> 
> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.

Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks

> 
> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.

Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory. 

Thanks & Regards,
Chris

> 
> Thanks,
> 
> Vyom
> 
> 
> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>> 
>> Regards,
>> Chris
> 


From Alan.Bateman at oracle.com  Mon Aug  6 10:23:36 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Aug 2018 11:23:36 +0100
Subject: RFR8194230, jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java
 fails with NPE
In-Reply-To: <73b18b56-5266-4274-f05a-75fcb87eef44@oracle.com>
References: <73b18b56-5266-4274-f05a-75fcb87eef44@oracle.com>
Message-ID: <181961ff-573a-dbff-7ba9-59d5e3afb980@oracle.com>

On 31/07/2018 07:16, Felix Yang wrote:
> Hi all,
>
> ??? please review a patch to improve the checking on the settings. 
> Originally it will throw NPE, if specified path is invalid.
>
> Bug:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8194230
>
> Webrev:
>
> ??? http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.00/
Have you considered merging getJdk8Path and isJdk8 so that it simple 
checks for the release file and rejects the value of JDK8_HOME when it 
doesn't exist? I think that should reduce the number of checks and keep 
it very simple.

-Alan

From forax at univ-mlv.fr  Mon Aug  6 12:15:28 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 6 Aug 2018 14:15:28 +0200 (CEST)
Subject: Deprecate java.io.File or at least some methods
Message-ID: <2059554422.30112.1533557728907.JavaMail.zimbra@u-pem.fr>

Hi all,
restarting discussion about JDK-8181098,
java.io.File has several severe issues so we should alert users to migrate to use java.nio.file.[Path|Files] ASAP using the deprecation mechanism (obviously not for removal).

The usual gotchas
- File used string name which may do not map correctly with the underlying file system charset.
- methods that are developer hostile 
  - methods that performs an action on the file system file returns a false if there is an issue instead of an IOException
  - methods that list files return null instead of an IOException if there is an issue.
- reading/writing into a file (using File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8.

I see two ways of deprecation, one is to deprecate the whole class, it has the advantage of making the things clear, the other is to deprecate the constructors and all methods that acts on the file of the file system. The later option allows library to still have methods that takes a java.io.File as parameter if their implementation use toPath() to perform the operations.

regards,
R?mi
   





From vyom.tewari at oracle.com  Mon Aug  6 12:38:33 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Mon, 6 Aug 2018 18:08:33 +0530
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
Message-ID: <bb23b246-8240-0a95-85ac-4e8d291b13dd@oracle.com>



On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
> Hi, Vyom
>
> Many thanks for your review and comments, inline and updated webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>
>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>
> Paste a few javadoc here against ?getObjectInstance? method as below
>
> * @return The object created; null if an object cannot be created.
> * @exception Exception If this object factory encountered an exception
> * while attempting to create an object, and no other object factories are
> * to be tried.
Yes you are right, we have to live with null.

Vyom
>> 2-> DirTxtFactory.java same as "DirFactory.java?.
> Same as above
>
>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>
>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>
> Thanks & Regards,
> Chris
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>
>>> Regards,
>>> Chris


From fweimer at redhat.com  Mon Aug  6 13:01:31 2018
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 6 Aug 2018 15:01:31 +0200
Subject: Adding new IBM extended charsets
In-Reply-To: <OF99360D63.F5BAF5C1-ON002582C2.004352A0-652582C2.00441936@notes.na.collabserv.com>
References: <OF20780B57.BDD380EA-ON002582C0.0044EDAF-652582C0.0045C303@notes.na.collabserv.com>
 <36548af8-d5fd-204f-d08e-fc60ffbc09a9@redhat.com>
 <OF99360D63.F5BAF5C1-ON002582C2.004352A0-652582C2.00441936@notes.na.collabserv.com>
Message-ID: <737abb40-d231-cbd8-48eb-9eeb10885c39@redhat.com>

On 07/06/2018 02:23 PM, Nasser Ebrahim wrote:
> Hi Florian,
> 
> Thank you for your response. iconv is platform dependent and not good for
> the platform agnostic nature of Java. Also, many charsets in Java are not
> available across platforms. I believe Java decided to have its own
> charsets due to those reasons so that it can work seamlessly on any
> supported platforms.

But then the tables will occasionally be different from what the 
platform uses for conversation.  Wouldn't be compatibility with the rest 
of the system installation be preferred in this context?

Thanks,
Florian

From Roger.Riggs at Oracle.com  Mon Aug  6 14:58:49 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 6 Aug 2018 10:58:49 -0400
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
 <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
 <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>
Message-ID: <a8609400-6797-dd5c-ca1f-e045998f2d59@Oracle.com>

Hi Chris,

EnvTestBase.java:? The class and each of the methods should have javadoc 
with a descriptive comment
to make the test construction easier to understand for future 
maintenance especially since
they are shared/overridden and used by many of the test cases.
For example, verifyEnvProperty should say what is true about a valid 
property.
With many layers of inherited test methods it needs easier to understand 
what comes from where.
Build good habits with writing complete sentences with capitalization 
and punctuation in comments.

initContext() belongs in DNSTestBase along with context() and 
setContext() to avoid splitting that
function across multiple classes.
Or remove initContext() since it is overridden in several tests (without 
calling super) and
just call setContext() with new InitialDirContext(env()) consistently in 
each test.

ProviderUrlGen.java should not mention SWAN by name as it is an internal 
resource
(and that's not the current name).

RemoveInherited.java: for strings that need to be consistent across the 
test, they should be defined as
final statics so there is only one declaration.

Thanks, Roger

On 8/6/2018 3:09 AM, Chris Yin wrote:
> Thank you, Vyom
>
> Regards,
> Chris
>
>> On 6 Aug 2018, at 2:02 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Latest webrev looks good to me.
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
>>> Hi, Vyom
>>>
>>> Thank a lot for your review and comments, inline and update new webrev as below
>>>
>>> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/
>>>
>>>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>
>>>> Hi Chris,
>>>>
>>>> Overall looks good to me, couple of minor comment.
>>>>
>>>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
>>> Fixed, thanks
>>>
>>>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
>>> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>>>
>>> Thanks,
>>> Chris
>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>>>
>>>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>>>
>>>>>> Regards,
>>>>>> Chris


From mearvk at outlook.com  Mon Aug  6 15:55:53 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 6 Aug 2018 15:55:53 +0000
Subject: System.java Development Question
In-Reply-To: <c930a283-43c5-b5bb-11d4-a1e822ae4788@oracle.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <c930a283-43c5-b5bb-11d4-a1e822ae4788@oracle.com>
Message-ID: <SN6PR07MB5022D9E9DC8D3C4B4C14C7A1DA200@SN6PR07MB5022.namprd07.prod.outlook.com>

Clases, Hello.


Firstly thank you for replying.  Of course our goal is to show the strengths in the OpenJDK.


Some weeks ago we were working with the ClassFileTransformer as an initial hook for a modest databasing proposal.  We found it to be a dead end.


Of course the company has greenlit further work into the area.  We would like to point out JDK did not have any way to hook the malloc sequence at the time.


Please refer us to the technical lay for the Overhead Heap-Profiling reference you refer to; Ok.


Thanks,


Max R.

________________________________
From: Claes Redestad <claes.redestad at oracle.com>
Sent: Monday, August 6, 2018 2:12:35 AM
To: core-libs-dev at openjdk.java.net; mearvk at outlook.com
Subject: Re: System.java Development Question

On 2018-08-04 14:29, mr rupplin wrote:
> Any help?

I think it would help if you described what you're trying to achieve,
rather than the current stumbling block.[0]

Reading between the lines then it seems you're trying to add some kind
of adhoc allocation profiling, so I wonder if you've seen the Low
Overhead Heap-Profiling work that went into jdk/jdk just a few weeks
ago?[1]

If it doesn't fit your use-case - or you really need something like it
applied to JDK 9 - it might still be good advice to study the code and
approach taken there before reverse-engineering the entire OpenJDK
source code... :-)

/Claes

[0] https://en.wikipedia.org/wiki/XY_problem
[1] Initial implementation:
http://hg.openjdk.java.net/jdk/jdk/rev/e2a7f431f65c
Impl RFE: https://bugs.openjdk.java.net/browse/JDK-8203394
JEP: https://bugs.openjdk.java.net/browse/JDK-8203394

(See the JEP for follow-up bug fixes you'd need to consider if you'd
ever attempt to backport this)

From daniel.daugherty at oracle.com  Mon Aug  6 16:49:47 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 12:49:47 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
Message-ID: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>

Greetings,

I'm in the process of reducing the noise in the JDK12 CI so
I need a single (R)eviewer for the following fix:

 ??? JDK-8209018 ProblemList tests affected by JDK-8208690
 ??? https://bugs.openjdk.java.net/browse/JDK-8209018

Here's the diff:

$ hg diff
diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
+++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
@@ -59,6 +59,9 @@

 ?compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 
generic-all

+compiler/c1/Test4917709.java 8208690 generic-all
+compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
+
 ?#############################################################################

 ?# :hotspot_gc
diff -r c00451b67854 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
+++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
@@ -559,6 +559,9 @@

 ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all

+java/net/Socket/LingerTest.java 8208690 generic-all
+sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
+
 ?############################################################################

 ?# jdk_nio


Thanks, in advance, for any questions, comments or suggestions.

Dan

From ted at tedneward.com  Fri Aug  3 19:26:03 2018
From: ted at tedneward.com (ted at tedneward.com)
Date: Fri, 3 Aug 2018 12:26:03 -0700
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>

Hey, all; did this get resolved? I'm still getting this error in
pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer not to
make local changes (mostly I want to build debug builds so I can spelunk the
JVM bits), but if this isn't going to roll out fairly shortly I'll disable
warnings-as-errors and carry on.

Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com

-----Original Message-----
From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Pengfei Li
Sent: Thursday, June 28, 2018 3:01 AM
To: kim.barrett at oracle.com; bsrbnd at gmail.com
Cc: build-dev at openjdk.java.net; nd <nd at arm.com>;
core-libs-dev at openjdk.java.net
Subject: RFR: 8202794: Native Unix code should use readdir rather than
readdir_r

Hi

Last month, Bernard proposed a patch to fix the OpenJDK build issue with
recent versions of glibc.
See
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html
But this fix requires to be tested on all POSIX systems before getting
integrated.

As recently, more and more guys are complaining about the OpenJDK build
failure issue, shall we just add the following workaround to upstream before
Bernard's real fix eventually merged?


diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c
b/src/java.base/unix/native/libjava/TimeZone_md.c
index f0bb362afc..e156381acd 100644
--- a/src/java.base/unix/native/libjava/TimeZone_md.c
+++ b/src/java.base/unix/native/libjava/TimeZone_md.c
@@ -146,7 +146,7 @@ findZoneinfoFile(char *buf, size_t size, const char
*dir)
         (void) closedir(dirp);
         return NULL;
     }
-
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) {
         /*
          * Skip '.' and '..' (and possibly other .* files) diff --git
a/src/java.base/unix/native/libjava/UnixFileSystem_md.c
b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
index 315aa92b64..5b9554dd47 100644
--- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c
+++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
@@ -339,6 +339,7 @@ Java_java_io_UnixFileSystem_list(JNIEnv *env, jobject
this,
     if (rv == NULL) goto error;

     /* Scan the directory */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     while ((readdir64_r(dir, ptr, &result) == 0)  && (result != NULL)) {
         jstring name;
         if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) diff
--git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
index 53bb1c1009..72c38eb9a6 100644
--- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
+++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
@@ -731,6 +731,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv*
env, jclass this, jlong val

     /* EINTR not listed as a possible error */
     /* TDB: reentrant version probably not required here */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     res = readdir64_r(dirp, ptr, &result);

#ifdef _AIX
diff --git
a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
index 1adeaf7bb5..080cf2a89b 100644
--- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
+++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemIm
+++ pl.c
@@ -80,6 +80,7 @@ static struct dirent* read_dir(DIR* dirp, struct dirent*
entry) {
     return dbuf;
#else /* __linux__ || _ALLBSD_SOURCE */
     struct dirent* p;
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
     if (readdir_r(dirp, entry, &p) == 0) {
         return p;
     } else {


--
Thanks,
Pengfei


From ted at tedneward.com  Mon Aug  6 06:08:21 2018
From: ted at tedneward.com (ted at tedneward.com)
Date: Sun, 5 Aug 2018 23:08:21 -0700
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
Message-ID: <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>

Assuming I want to build JDK 8/9/10/11 (for research and spelunking purposes), what's the best way to do that if the changes aren't going to be backported? Turn off the warnings-as-errors (and what's the best way to do that), or somehow downgrade glibc (on my Ubuntu 18 image)? I could use advice/assistance on either approach.

Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: Sunday, August 5, 2018 11:08 AM
To: ted at tedneward.com; 'Pengfei Li' <Pengfei.Li at arm.com>; kim.barrett at oracle.com; bsrbnd at gmail.com
Cc: build-dev at openjdk.java.net; 'nd' <nd at arm.com>; core-libs-dev at openjdk.java.net
Subject: Re: 8202794: Native Unix code should use readdir rather than readdir_r

On 03/08/2018 20:26, ted at tedneward.com wrote:
> Hey, all; did this get resolved? I'm still getting this error in 
> pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer 
> not to make local changes (mostly I want to build debug builds so I 
> can spelunk the JVM bits), but if this isn't going to roll out fairly 
> shortly I'll disable warnings-as-errors and carry on.
>
The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in jdk/jdk for JDK 12. There are few residual issues/inconsistencies that came up and are still under discussion on the mailing lists. I don't think there has been any discussion yet about back porting.

-Alan


From ted at tedneward.com  Mon Aug  6 08:32:20 2018
From: ted at tedneward.com (ted at tedneward.com)
Date: Mon, 6 Aug 2018 01:32:20 -0700
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
 <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>
 <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <00e901d42d5f$fea5d190$fbf174b0$@tedneward.com>

Well, that works for JDK 10, it seems... (building now...) but is there a similar way to disable warnings for JDK 8 and 9? Some combination of CFLAGS/CPPFLAGS, perhaps? I'd really like to be able to build 8 and 9; particularly 8, since that's what my current employer is still using. :-)

Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com

-----Original Message-----
From: Pengfei Li <Pengfei.Li at arm.com> 
Sent: Sunday, August 5, 2018 11:26 PM
To: ted at tedneward.com; 'Alan Bateman' <Alan.Bateman at oracle.com>; kim.barrett at oracle.com; bsrbnd at gmail.com
Cc: build-dev at openjdk.java.net; nd <nd at arm.com>; core-libs-dev at openjdk.java.net
Subject: RE: 8202794: Native Unix code should use readdir rather than readdir_r

Ted,

I just use --disable-warnings-as-errors in bash configure command to build jdk 10/11 on Ubuntu 18.

--
Thanks,
Pengfei

> 
> Assuming I want to build JDK 8/9/10/11 (for research and spelunking 
> purposes), what's the best way to do that if the changes aren't going 
> to be backported? Turn off the warnings-as-errors (and what's the best 
> way to do that), or somehow downgrade glibc (on my Ubuntu 18 image)? I 
> could use advice/assistance on either approach.
> 
> Ted Neward
> Technologist and Leader
> T: @tedneward | M: (425) 647-4526
> http://www.newardassociates.com
> 
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Sunday, August 5, 2018 11:08 AM
> To: ted at tedneward.com; 'Pengfei Li' <Pengfei.Li at arm.com>; 
> kim.barrett at oracle.com; bsrbnd at gmail.com
> Cc: build-dev at openjdk.java.net; 'nd' <nd at arm.com>; core-libs- 
> dev at openjdk.java.net
> Subject: Re: 8202794: Native Unix code should use readdir rather than 
> readdir_r
> 
> On 03/08/2018 20:26, ted at tedneward.com wrote:
> > Hey, all; did this get resolved? I'm still getting this error in 
> > pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer 
> > not to make local changes (mostly I want to build debug builds so I 
> > can spelunk the JVM bits), but if this isn't going to roll out 
> > fairly shortly I'll disable warnings-as-errors and carry on.
> >
> The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in 
> jdk/jdk for JDK 12. There are few residual issues/inconsistencies that 
> came up and are still under discussion on the mailing lists. I don't 
> think there has been any discussion yet about back porting.
> 
> -Alan



From ted at tedneward.com  Mon Aug  6 08:33:22 2018
From: ted at tedneward.com (ted at tedneward.com)
Date: Mon, 6 Aug 2018 01:33:22 -0700
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
 <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>
 <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>
Message-ID: <00ea01d42d60$2345bbf0$69d133d0$@tedneward.com>

And forgot to lead with: Thanks, Pengfei! That helps a great deal.

Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com

-----Original Message-----
From: Pengfei Li <Pengfei.Li at arm.com> 
Sent: Sunday, August 5, 2018 11:26 PM
To: ted at tedneward.com; 'Alan Bateman' <Alan.Bateman at oracle.com>; kim.barrett at oracle.com; bsrbnd at gmail.com
Cc: build-dev at openjdk.java.net; nd <nd at arm.com>; core-libs-dev at openjdk.java.net
Subject: RE: 8202794: Native Unix code should use readdir rather than readdir_r

Ted,

I just use --disable-warnings-as-errors in bash configure command to build jdk 10/11 on Ubuntu 18.

--
Thanks,
Pengfei

> 
> Assuming I want to build JDK 8/9/10/11 (for research and spelunking 
> purposes), what's the best way to do that if the changes aren't going 
> to be backported? Turn off the warnings-as-errors (and what's the best 
> way to do that), or somehow downgrade glibc (on my Ubuntu 18 image)? I 
> could use advice/assistance on either approach.
> 
> Ted Neward
> Technologist and Leader
> T: @tedneward | M: (425) 647-4526
> http://www.newardassociates.com
> 
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Sunday, August 5, 2018 11:08 AM
> To: ted at tedneward.com; 'Pengfei Li' <Pengfei.Li at arm.com>; 
> kim.barrett at oracle.com; bsrbnd at gmail.com
> Cc: build-dev at openjdk.java.net; 'nd' <nd at arm.com>; core-libs- 
> dev at openjdk.java.net
> Subject: Re: 8202794: Native Unix code should use readdir rather than 
> readdir_r
> 
> On 03/08/2018 20:26, ted at tedneward.com wrote:
> > Hey, all; did this get resolved? I'm still getting this error in 
> > pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer 
> > not to make local changes (mostly I want to build debug builds so I 
> > can spelunk the JVM bits), but if this isn't going to roll out 
> > fairly shortly I'll disable warnings-as-errors and carry on.
> >
> The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in 
> jdk/jdk for JDK 12. There are few residual issues/inconsistencies that 
> came up and are still under discussion on the mailing lists. I don't 
> think there has been any discussion yet about back porting.
> 
> -Alan



From ted at tedneward.com  Mon Aug  6 08:56:29 2018
From: ted at tedneward.com (ted at tedneward.com)
Date: Mon, 6 Aug 2018 01:56:29 -0700
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <f00aec93c61373f3170e8bb0373da125fc5f4ebd.camel@redhat.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>	
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>	
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>	
 <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>	
 <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>	
 <00e901d42d5f$fea5d190$fbf174b0$@tedneward.com>
 <f00aec93c61373f3170e8bb0373da125fc5f4ebd.camel@redhat.com>
Message-ID: <00f101d42d63$5e4724c0$1ad56e40$@tedneward.com>

Giving that a spin now; thanks!

Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com

-----Original Message-----
From: Severin Gehwolf <sgehwolf at redhat.com> 
Sent: Monday, August 6, 2018 1:46 AM
To: ted at tedneward.com; 'Pengfei Li' <Pengfei.Li at arm.com>; 'Alan Bateman' <Alan.Bateman at oracle.com>; kim.barrett at oracle.com; bsrbnd at gmail.com
Cc: build-dev at openjdk.java.net; 'nd' <nd at arm.com>; core-libs-dev at openjdk.java.net
Subject: Re: 8202794: Native Unix code should use readdir rather than readdir_r

On Mon, 2018-08-06 at 01:32 -0700, ted at tedneward.com wrote:
> I'd really like to be able to build 8 and 9; particularly 8, since 
> that's what my current employer is still using. :-)

For JDK 8 we have to use:

$ bash configure ...
$ make WARNINGS_ARE_ERRORS="" \
      SCTP_WERROR= \
      ...

JDK 9+ have --disable-warnings-as-errors configure option.

Thanks,
Severin


From Pengfei.Li at arm.com  Mon Aug  6 06:25:47 2018
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Mon, 6 Aug 2018 06:25:47 +0000
Subject: 8202794: Native Unix code should use readdir rather than readdir_r
In-Reply-To: <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>
References: <DB7PR08MB3115E2A6337D179D008F5026964F0@DB7PR08MB3115.eurprd08.prod.outlook.com>
 <0d1e01d42b5f$d2aa2340$77fe69c0$@tedneward.com>
 <201e25b3-889d-2b38-a77b-b28a5a6747d7@oracle.com>
 <00b701d42d4b$e4af7c50$ae0e74f0$@tedneward.com>
Message-ID: <DB7PR08MB3115625A47FC940D214E3A3F96200@DB7PR08MB3115.eurprd08.prod.outlook.com>

Ted,

I just use --disable-warnings-as-errors in bash configure command to build jdk 10/11 on Ubuntu 18.

--
Thanks,
Pengfei

> 
> Assuming I want to build JDK 8/9/10/11 (for research and spelunking
> purposes), what's the best way to do that if the changes aren't going to be
> backported? Turn off the warnings-as-errors (and what's the best way to do
> that), or somehow downgrade glibc (on my Ubuntu 18 image)? I could use
> advice/assistance on either approach.
> 
> Ted Neward
> Technologist and Leader
> T: @tedneward | M: (425) 647-4526
> http://www.newardassociates.com
> 
> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Sunday, August 5, 2018 11:08 AM
> To: ted at tedneward.com; 'Pengfei Li' <Pengfei.Li at arm.com>;
> kim.barrett at oracle.com; bsrbnd at gmail.com
> Cc: build-dev at openjdk.java.net; 'nd' <nd at arm.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: 8202794: Native Unix code should use readdir rather than
> readdir_r
> 
> On 03/08/2018 20:26, ted at tedneward.com wrote:
> > Hey, all; did this get resolved? I'm still getting this error in
> > pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer
> > not to make local changes (mostly I want to build debug builds so I
> > can spelunk the JVM bits), but if this isn't going to roll out fairly
> > shortly I'll disable warnings-as-errors and carry on.
> >
> The changes for JDK-8202353, JDK-8202794, and JDK-8207340 are in jdk/jdk
> for JDK 12. There are few residual issues/inconsistencies that came up and
> are still under discussion on the mailing lists. I don't think there has been any
> discussion yet about back porting.
> 
> -Alan


From albi646 at gmx.de  Sun Aug  5 19:54:12 2018
From: albi646 at gmx.de (Albert Schimpf)
Date: Sun, 5 Aug 2018 21:54:12 +0200
Subject: [httpclient] HTTP2: Memory Leak with Proxy
Message-ID: <24022e30-dcdf-3766-7fd6-e6c5f46674a0@gmx.de>

Hi,

I stumbled upon some strange behavior when using the new Java httpclient.

The issue is very simple to reproduce. Send a GET request via a known 
bad proxy:

HttpClient client = HttpClient.newBuilder()
 ??????????????????? .proxy(ProxySelector.of(BAD_PROXY))
 ??????????????????? .build();

HttpRequest req = HttpRequest
 ??????????????????? // target is not relevant
 ??????????????????? .newBuilder(...)
 ??????????????????? .GET()
 ??????????????????? .build();

// body handler is not relevant
HttpResponse.BodyHandler<?> t = HttpResponse.BodyHandler.asString();

// happens with both async and sync send
client.sendAsync(req, t).get(30, TimeUnit.SECONDS);

The result is that the heap size increases dramatically (to about 1.5GB) 
and resources are not released. CPU consumption increases by a constant 
factor, too. I have tried many variations of the above code, and the 
only thing which seems to work (i.e. heap size does not explode) is to 
set the HTTP version to 1.1.

In my main application this leads to both memory and CPU starvation (4GB 
memory limit, 100% CPU usage). It usually uses only 5% CPU and 200MB 
memory at worst.

I have attached a working example code with a bad proxy. I uploaded the 
generated garbage collection log and three heap dumps (before, during, 
and after the request) to dropbox:

https://www.dropbox.com/s/ulqnmrmgr58rrul/debug.zip

I tried the 10.0.0-openjdk and 10.0.1-zulu version. I can reproduce the 
issue 100% of times.

Am I doing something wrong? Is this to be expected if one somehow 
happens to use a bad proxy? If this is to be expected, how can I protect 
my application against such behavior?

Best,

Albert

From vladimir.kozlov at oracle.com  Mon Aug  6 16:59:17 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 6 Aug 2018 09:59:17 -0700
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
Message-ID: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>

Hi Dan,

8208690 lists only next 2 tests:

sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
java/net/Socket/LingerTest.java (2 instances)

Why you also added 2 compiler tests?

Thanks,
Vladimir

On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
> Greetings,
> 
> I'm in the process of reducing the noise in the JDK12 CI so
> I need a single (R)eviewer for the following fix:
> 
>  ??? JDK-8209018 ProblemList tests affected by JDK-8208690
>  ??? https://bugs.openjdk.java.net/browse/JDK-8209018
> 
> Here's the diff:
> 
> $ hg diff
> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
> @@ -59,6 +59,9 @@
> 
>  ?compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all
> 
> +compiler/c1/Test4917709.java 8208690 generic-all
> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
> +
>  ?#############################################################################
> 
>  ?# :hotspot_gc
> diff -r c00451b67854 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
> @@ -559,6 +559,9 @@
> 
>  ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all
> 
> +java/net/Socket/LingerTest.java 8208690 generic-all
> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
> +
>  ?############################################################################
> 
>  ?# jdk_nio
> 
> 
> Thanks, in advance, for any questions, comments or suggestions.
> 
> Dan

From daniel.daugherty at oracle.com  Mon Aug  6 17:01:18 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 13:01:18 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
Message-ID: <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>

On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
> Hi Dan,
>
> 8208690 lists only next 2 tests:
>
> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
> java/net/Socket/LingerTest.java (2 instances)
>
> Why you also added 2 compiler tests?

If you look at all the sightings in the bug report, you'll
see the two compiler tests listed in different entries.
The compiler test failures are intermittent, but the other
two happen in every tier2...

Dan


>
> Thanks,
> Vladimir
>
> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I'm in the process of reducing the noise in the JDK12 CI so
>> I need a single (R)eviewer for the following fix:
>>
>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>
>> Here's the diff:
>>
>> $ hg diff
>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 
>> -0400
>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 
>> -0400
>> @@ -59,6 +59,9 @@
>>
>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 
>> generic-all
>>
>> +compiler/c1/Test4917709.java 8208690 generic-all
>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>> +
>> ??############################################################################# 
>>
>>
>> ??# :hotspot_gc
>> diff -r c00451b67854 test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>> @@ -559,6 +559,9 @@
>>
>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 
>> macosx-all
>>
>> +java/net/Socket/LingerTest.java 8208690 generic-all
>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>> +
>> ??############################################################################ 
>>
>>
>> ??# jdk_nio
>>
>>
>> Thanks, in advance, for any questions, comments or suggestions.
>>
>> Dan


From vladimir.kozlov at oracle.com  Mon Aug  6 17:14:46 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 6 Aug 2018 10:14:46 -0700
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
Message-ID: <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>

Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use /othervm):

"Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm mode. 
jtreg can't know how to make these threads terminate."

Test4917709.java is closed test, not open.

File a separate bug and I will fix these 2 tests.

Regards,
Vladimir

On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>> Hi Dan,
>>
>> 8208690 lists only next 2 tests:
>>
>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>> java/net/Socket/LingerTest.java (2 instances)
>>
>> Why you also added 2 compiler tests?
> 
> If you look at all the sightings in the bug report, you'll
> see the two compiler tests listed in different entries.
> The compiler test failures are intermittent, but the other
> two happen in every tier2...
> 
> Dan
> 
> 
>>
>> Thanks,
>> Vladimir
>>
>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I'm in the process of reducing the noise in the JDK12 CI so
>>> I need a single (R)eviewer for the following fix:
>>>
>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>
>>> Here's the diff:
>>>
>>> $ hg diff
>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>> @@ -59,6 +59,9 @@
>>>
>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all
>>>
>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>> +
>>> ??#############################################################################
>>>
>>> ??# :hotspot_gc
>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>> @@ -559,6 +559,9 @@
>>>
>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all
>>>
>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>>> +
>>> ??############################################################################
>>>
>>> ??# jdk_nio
>>>
>>>
>>> Thanks, in advance, for any questions, comments or suggestions.
>>>
>>> Dan
> 

From daniel.daugherty at oracle.com  Mon Aug  6 17:25:34 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 13:25:34 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
Message-ID: <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>

On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
> Okay, I read more about what happened. I think compiler tests should 
> be modified as David Holmes suggested (use /othervm):
>
> "Tests that don't manage their threads properly (ie ensure they 
> terminate at test end) should be run in othervm mode. jtreg can't know 
> how to make these threads terminate."
>
> Test4917709.java is closed test, not open.

Oops. I'll have to clean that up.


> File a separate bug and I will fix these 2 tests.

So are you saying not to ProblemList these two tests and
that I should file a new bug and you'll take care of it?

Dan


>
> Regards,
> Vladimir
>
> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>> Hi Dan,
>>>
>>> 8208690 lists only next 2 tests:
>>>
>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>> java/net/Socket/LingerTest.java (2 instances)
>>>
>>> Why you also added 2 compiler tests?
>>
>> If you look at all the sightings in the bug report, you'll
>> see the two compiler tests listed in different entries.
>> The compiler test failures are intermittent, but the other
>> two happen in every tier2...
>>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>> I need a single (R)eviewer for the following fix:
>>>>
>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>
>>>> Here's the diff:
>>>>
>>>> $ hg diff
>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 
>>>> 2018 -0400
>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 
>>>> 2018 -0400
>>>> @@ -59,6 +59,9 @@
>>>>
>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 
>>>> generic-all
>>>>
>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>> +
>>>> ??############################################################################# 
>>>>
>>>>
>>>> ??# :hotspot_gc
>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>> @@ -559,6 +559,9 @@
>>>>
>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 
>>>> macosx-all
>>>>
>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>>>> +
>>>> ??############################################################################ 
>>>>
>>>>
>>>> ??# jdk_nio
>>>>
>>>>
>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>
>>>> Dan
>>


From vladimir.kozlov at oracle.com  Mon Aug  6 17:41:19 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 6 Aug 2018 10:41:19 -0700
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
 <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
Message-ID: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>

On 8/6/18 10:25 AM, Daniel D. Daugherty wrote:
> On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
>> Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use 
>> /othervm):
>>
>> "Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm mode. 
>> jtreg can't know how to make these threads terminate."
>>
>> Test4917709.java is closed test, not open.
> 
> Oops. I'll have to clean that up.
> 
> 
>> File a separate bug and I will fix these 2 tests.
> 
> So are you saying not to ProblemList these two tests and
> that I should file a new bug and you'll take care of it?

Yes.

Vladimir

> 
> Dan
> 
> 
>>
>> Regards,
>> Vladimir
>>
>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>>> Hi Dan,
>>>>
>>>> 8208690 lists only next 2 tests:
>>>>
>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>>> java/net/Socket/LingerTest.java (2 instances)
>>>>
>>>> Why you also added 2 compiler tests?
>>>
>>> If you look at all the sightings in the bug report, you'll
>>> see the two compiler tests listed in different entries.
>>> The compiler test failures are intermittent, but the other
>>> two happen in every tier2...
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>>> I need a single (R)eviewer for the following fix:
>>>>>
>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>>
>>>>> Here's the diff:
>>>>>
>>>>> $ hg diff
>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>> @@ -59,6 +59,9 @@
>>>>>
>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all
>>>>>
>>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>>> +
>>>>> ??#############################################################################
>>>>>
>>>>> ??# :hotspot_gc
>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>> @@ -559,6 +559,9 @@
>>>>>
>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all
>>>>>
>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>>>>> +
>>>>> ??############################################################################
>>>>>
>>>>> ??# jdk_nio
>>>>>
>>>>>
>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>
>>>>> Dan
>>>
> 

From daniel.daugherty at oracle.com  Mon Aug  6 17:43:59 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 13:43:59 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
 <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
 <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
Message-ID: <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com>

On 8/6/18 1:41 PM, Vladimir Kozlov wrote:
> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote:
>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
>>> Okay, I read more about what happened. I think compiler tests should 
>>> be modified as David Holmes suggested (use /othervm):
>>>
>>> "Tests that don't manage their threads properly (ie ensure they 
>>> terminate at test end) should be run in othervm mode. jtreg can't 
>>> know how to make these threads terminate."
>>>
>>> Test4917709.java is closed test, not open.
>>
>> Oops. I'll have to clean that up.
>>
>>
>>> File a separate bug and I will fix these 2 tests.
>>
>> So are you saying not to ProblemList these two tests and
>> that I should file a new bug and you'll take care of it?
>
> Yes.

Okay I'll do that.

Can I list you as the (R)eviewer for ProblemListing these two tests?

sun/net/www/http/HttpClient/MultiThreadTest.java
java/net/Socket/LingerTest.java

Dan


>
> Vladimir
>
>>
>> Dan
>>
>>
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>>>> Hi Dan,
>>>>>
>>>>> 8208690 lists only next 2 tests:
>>>>>
>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>>>> java/net/Socket/LingerTest.java (2 instances)
>>>>>
>>>>> Why you also added 2 compiler tests?
>>>>
>>>> If you look at all the sightings in the bug report, you'll
>>>> see the two compiler tests listed in different entries.
>>>> The compiler test failures are intermittent, but the other
>>>> two happen in every tier2...
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>>>> I need a single (R)eviewer for the following fix:
>>>>>>
>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>>>
>>>>>> Here's the diff:
>>>>>>
>>>>>> $ hg diff
>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 
>>>>>> 2018 -0400
>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 
>>>>>> 2018 -0400
>>>>>> @@ -59,6 +59,9 @@
>>>>>>
>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 
>>>>>> 8190680 generic-all
>>>>>>
>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>>>> +
>>>>>> ??############################################################################# 
>>>>>>
>>>>>>
>>>>>> ??# :hotspot_gc
>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>>> @@ -559,6 +559,9 @@
>>>>>>
>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 
>>>>>> macosx-all
>>>>>>
>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 
>>>>>> generic-all
>>>>>> +
>>>>>> ??############################################################################ 
>>>>>>
>>>>>>
>>>>>> ??# jdk_nio
>>>>>>
>>>>>>
>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>
>>>>>> Dan
>>>>
>>


From vladimir.kozlov at oracle.com  Mon Aug  6 17:52:41 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 6 Aug 2018 10:52:41 -0700
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
 <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
 <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
 <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com>
Message-ID: <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com>

On 8/6/18 10:43 AM, Daniel D. Daugherty wrote:
> On 8/6/18 1:41 PM, Vladimir Kozlov wrote:
>> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote:
>>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
>>>> Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use 
>>>> /othervm):
>>>>
>>>> "Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm 
>>>> mode. jtreg can't know how to make these threads terminate."
>>>>
>>>> Test4917709.java is closed test, not open.
>>>
>>> Oops. I'll have to clean that up.
>>>
>>>
>>>> File a separate bug and I will fix these 2 tests.
>>>
>>> So are you saying not to ProblemList these two tests and
>>> that I should file a new bug and you'll take care of it?
>>
>> Yes.
> 
> Okay I'll do that.
> 
> Can I list you as the (R)eviewer for ProblemListing these two tests?

yes.

> 
> sun/net/www/http/HttpClient/MultiThreadTest.java
> java/net/Socket/LingerTest.java
> 
> Dan
> 
> 
>>
>> Vladimir
>>
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>>>>> Hi Dan,
>>>>>>
>>>>>> 8208690 lists only next 2 tests:
>>>>>>
>>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>>>>> java/net/Socket/LingerTest.java (2 instances)
>>>>>>
>>>>>> Why you also added 2 compiler tests?
>>>>>
>>>>> If you look at all the sightings in the bug report, you'll
>>>>> see the two compiler tests listed in different entries.
>>>>> The compiler test failures are intermittent, but the other
>>>>> two happen in every tier2...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>>>>> I need a single (R)eviewer for the following fix:
>>>>>>>
>>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>>>>
>>>>>>> Here's the diff:
>>>>>>>
>>>>>>> $ hg diff
>>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>>>> @@ -59,6 +59,9 @@
>>>>>>>
>>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all
>>>>>>>
>>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>>>>> +
>>>>>>> ??#############################################################################
>>>>>>>
>>>>>>> ??# :hotspot_gc
>>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>>>> @@ -559,6 +559,9 @@
>>>>>>>
>>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all
>>>>>>>
>>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>>>>>>> +
>>>>>>> ??############################################################################
>>>>>>>
>>>>>>> ??# jdk_nio
>>>>>>>
>>>>>>>
>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>
>>>
> 

From daniel.daugherty at oracle.com  Mon Aug  6 17:55:14 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 13:55:14 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
 <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
 <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
 <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com>
 <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com>
Message-ID: <b9249a64-0091-5e1f-1a76-3239590480b2@oracle.com>

On 8/6/18 1:52 PM, Vladimir Kozlov wrote:
> On 8/6/18 10:43 AM, Daniel D. Daugherty wrote:
>> On 8/6/18 1:41 PM, Vladimir Kozlov wrote:
>>> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote:
>>>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
>>>>> Okay, I read more about what happened. I think compiler tests 
>>>>> should be modified as David Holmes suggested (use /othervm):
>>>>>
>>>>> "Tests that don't manage their threads properly (ie ensure they 
>>>>> terminate at test end) should be run in othervm mode. jtreg can't 
>>>>> know how to make these threads terminate."
>>>>>
>>>>> Test4917709.java is closed test, not open.
>>>>
>>>> Oops. I'll have to clean that up.
>>>>
>>>>
>>>>> File a separate bug and I will fix these 2 tests.
>>>>
>>>> So are you saying not to ProblemList these two tests and
>>>> that I should file a new bug and you'll take care of it?
>>>
>>> Yes.
>>
>> Okay I'll do that.
>>
>> Can I list you as the (R)eviewer for ProblemListing these two tests?
>
> yes.

Thanks!

Dan


>
>>
>> sun/net/www/http/HttpClient/MultiThreadTest.java
>> java/net/Socket/LingerTest.java
>>
>> Dan
>>
>>
>>>
>>> Vladimir
>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>>>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> 8208690 lists only next 2 tests:
>>>>>>>
>>>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>>>>>> java/net/Socket/LingerTest.java (2 instances)
>>>>>>>
>>>>>>> Why you also added 2 compiler tests?
>>>>>>
>>>>>> If you look at all the sightings in the bug report, you'll
>>>>>> see the two compiler tests listed in different entries.
>>>>>> The compiler test failures are intermittent, but the other
>>>>>> two happen in every tier2...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>>>>>> Greetings,
>>>>>>>>
>>>>>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>>>>>> I need a single (R)eviewer for the following fix:
>>>>>>>>
>>>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>>>>>
>>>>>>>> Here's the diff:
>>>>>>>>
>>>>>>>> $ hg diff
>>>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 
>>>>>>>> 2018 -0400
>>>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 
>>>>>>>> 2018 -0400
>>>>>>>> @@ -59,6 +59,9 @@
>>>>>>>>
>>>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 
>>>>>>>> 8190680 generic-all
>>>>>>>>
>>>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>>>>>> +
>>>>>>>> ??############################################################################# 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??# :hotspot_gc
>>>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>>>>> @@ -559,6 +559,9 @@
>>>>>>>>
>>>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 
>>>>>>>> macosx-all
>>>>>>>>
>>>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 
>>>>>>>> generic-all
>>>>>>>> +
>>>>>>>> ??############################################################################ 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??# jdk_nio
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>
>>>>>>>> Dan
>>>>>>
>>>>
>>


From daniel.daugherty at oracle.com  Mon Aug  6 18:09:04 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 6 Aug 2018 14:09:04 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com>
 <e56eb882-1585-3745-fbee-60f71d097322@oracle.com>
 <d782f5f5-891d-16f6-c111-5e0732558cd2@oracle.com>
 <a0f9663c-ccaa-3483-2f85-500f6e97c5bc@oracle.com>
 <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com>
Message-ID: <48fad0d2-7d41-f621-d25a-570a357455f4@oracle.com>

On 8/6/18 1:41 PM, Vladimir Kozlov wrote:
> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote:
>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote:
>>> Okay, I read more about what happened. I think compiler tests should 
>>> be modified as David Holmes suggested (use /othervm):
>>>
>>> "Tests that don't manage their threads properly (ie ensure they 
>>> terminate at test end) should be run in othervm mode. jtreg can't 
>>> know how to make these threads terminate."
>>>
>>> Test4917709.java is closed test, not open.
>>
>> Oops. I'll have to clean that up.
>>
>>
>>> File a separate bug and I will fix these 2 tests.
>>
>> So are you saying not to ProblemList these two tests and
>> that I should file a new bug and you'll take care of it?
>
> Yes.

New bug has been filed:

 ??? JDK-8209023 fix 2 compiler tests to avoid JDK-8208690
 ??? https://bugs.openjdk.java.net/browse/JDK-8209023

and I have assigned it to you.

Dan


>
> Vladimir
>
>>
>> Dan
>>
>>
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote:
>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote:
>>>>> Hi Dan,
>>>>>
>>>>> 8208690 lists only next 2 tests:
>>>>>
>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances)
>>>>> java/net/Socket/LingerTest.java (2 instances)
>>>>>
>>>>> Why you also added 2 compiler tests?
>>>>
>>>> If you look at all the sightings in the bug report, you'll
>>>> see the two compiler tests listed in different entries.
>>>> The compiler test failures are intermittent, but the other
>>>> two happen in every tier2...
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I'm in the process of reducing the noise in the JDK12 CI so
>>>>>> I need a single (R)eviewer for the following fix:
>>>>>>
>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>>>>>
>>>>>> Here's the diff:
>>>>>>
>>>>>> $ hg diff
>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt
>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 
>>>>>> 2018 -0400
>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 
>>>>>> 2018 -0400
>>>>>> @@ -59,6 +59,9 @@
>>>>>>
>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 
>>>>>> 8190680 generic-all
>>>>>>
>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all
>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all
>>>>>> +
>>>>>> ??############################################################################# 
>>>>>>
>>>>>>
>>>>>> ??# :hotspot_gc
>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt
>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400
>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400
>>>>>> @@ -559,6 +559,9 @@
>>>>>>
>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 
>>>>>> macosx-all
>>>>>>
>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all
>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 
>>>>>> generic-all
>>>>>> +
>>>>>> ??############################################################################ 
>>>>>>
>>>>>>
>>>>>> ??# jdk_nio
>>>>>>
>>>>>>
>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>
>>>>>> Dan
>>>>
>>


From paul.sandoz at oracle.com  Mon Aug  6 18:13:19 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 6 Aug 2018 11:13:19 -0700
Subject: Long chains created by direct Buffer::slice
In-Reply-To: <a4047597-9e1b-8384-0f45-1d7155323efc@oracle.com>
References: <87o9f1n653.fsf@mid.deneb.enyo.de>
 <20180720111559.849741094@eggemoggin.niobe.net>
 <029E054A-7238-4271-AAC5-7904E86DB3D6@oracle.com>
 <87tvolksln.fsf@mid.deneb.enyo.de>
 <04231173-6899-4A4E-BF91-2ACA9AC6B5D4@oracle.com>
 <D1ED57AF-60C8-458E-92CB-1F4EDC0BB2A3@oracle.com>
 <a4047597-9e1b-8384-0f45-1d7155323efc@oracle.com>
Message-ID: <982909B3-AFC1-4FB8-8B78-F558E7AAEE13@oracle.com>

Thanks, i uploaded a new webrev in place that uses a similar technique to some stuff in j.u.concurrent tests.

Paul.

> On Aug 5, 2018, at 11:59 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 03/08/2018 23:15, Paul Sandoz wrote:
>> Got caught up with JVMLS this week?
>> 
>> I searched but could not find a test, so i added one, see:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8208362-direct-buffer-att/webrev/>
>> 
> One comment on the test is that the references to the intermediate refs may not be cleared immediately after the GC. It might be more reliable to loop, with a backoff, until at least one has been cleared.
> 
> -Alan


From claes.redestad at oracle.com  Mon Aug  6 18:20:38 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 6 Aug 2018 20:20:38 +0200
Subject: System.java Development Question
In-Reply-To: <SN6PR07MB5022D9E9DC8D3C4B4C14C7A1DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
 <c930a283-43c5-b5bb-11d4-a1e822ae4788@oracle.com>
 <SN6PR07MB5022D9E9DC8D3C4B4C14C7A1DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <c0994dc3-da00-2601-711b-ee4794b3bbd5@oracle.com>

Hi Max,


On 2018-08-06 17:55, mr rupplin wrote:
>
> Clases, Hello.
>
>
> Firstly thank you for replying.? Of course our goal is to show the 
> strengths in the OpenJDK.
>
>
> Some weeks ago we were working with the ClassFileTransformer as an 
> initial hook for a modest databasing proposal.? We found it to be a 
> dead end.
>
>
> Of course the company has greenlit further work into the area.? We 
> would like to point out JDK did not have any way to hook the malloc 
> sequence at the time.
>

it's great that you're showing an interest in the platform and exploring 
ways to extend/improve it.

It's somewhat coincidental that a lot of work happened in this 
particular area recently.

>
> Please refer us to the technical lay for the Overhead Heap-Profiling 
> reference you refer to; Ok.
>

I thought I already had, but it seems I referred to the initial 
implementation RFE twice. Sorry about that..

The high-level JEP is here: http://openjdk.java.net/jeps/331

It has the high-level overview. From there you can click through to JBS 
details for the JEP, and from there to the implementation.

For historical reference, initial discussion on the proposal here: 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-June/017543.html 


There were a couple of code reviews done on open lists, but I think this 
is the final round (and thread): 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023668.html

On top of the Low-Overhead Heap Profiling JEP mentioned, JFR was also 
open sourced in time for JDK 11. Perhaps it's memory allocation sampling 
is of interest and a workable alternative.

HTH!

/Claes

From mearvk at outlook.com  Mon Aug  6 18:21:55 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 6 Aug 2018 18:21:55 +0000
Subject: Core Type Compilation Issues
Message-ID: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>

Three problems that I run into when running the 'make jdk' after minor work on the System.java class for JNI and custom JDK:

java/lang/memory/GroupListener.java:111: warning: [rawtypes] found raw type: Class
        Class basetype = null;


-- --


java/lang/memory/GroupListener.java:7: error: package java.rmi does not exist
import java.rmi.Remote;


-- --


java/lang/memory/GroupListener.java:13: warning: [exports] class Group in module java.base is not accessible to clients that require this module
        public final ArrayList<Group> groups = new ArrayList<Group>();



== ==


Can we get explanations for each of these?  Also the solutions or workarounds.  OkQ!


Thanks,


Max R.


Software Lead

From Alan.Bateman at oracle.com  Mon Aug  6 18:30:37 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Aug 2018 19:30:37 +0100
Subject: [httpclient] HTTP2: Memory Leak with Proxy
In-Reply-To: <24022e30-dcdf-3766-7fd6-e6c5f46674a0@gmx.de>
References: <24022e30-dcdf-3766-7fd6-e6c5f46674a0@gmx.de>
Message-ID: <6db1d37c-a908-7ded-617b-a9016ef791ec@oracle.com>

On 05/08/2018 20:54, Albert Schimpf wrote:
> Hi,
>
> I stumbled upon some strange behavior when using the new Java httpclient.
>
Can you bring this to net-dev (as that is where the issues with the new 
HTTP client are being discussed)?

-Alan

From mearvk at outlook.com  Mon Aug  6 18:42:15 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 6 Aug 2018 18:42:15 +0000
Subject: System.java Development Question
In-Reply-To: <c0994dc3-da00-2601-711b-ee4794b3bbd5@oracle.com>
References: <SN6PR07MB50221EC22FC395106D6DE715DA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <3058463d-dd87-5777-4fa8-b4496c6f7ddb@oracle.com>
 <SN6PR07MB50222F5CCEDB52593762339CDA230@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB502290B3914975A3A15722CFDA220@SN6PR07MB5022.namprd07.prod.outlook.com>
 <c930a283-43c5-b5bb-11d4-a1e822ae4788@oracle.com>
 <SN6PR07MB5022D9E9DC8D3C4B4C14C7A1DA200@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <c0994dc3-da00-2601-711b-ee4794b3bbd5@oracle.com>
Message-ID: <SN6PR07MB5022CC25F7F3F15977FAD884DA200@SN6PR07MB5022.namprd07.prod.outlook.com>

That is alot of reading.  I will look into it.  We would build some according to the frameworks' ability to handle that control area.


Thank you.  I will be in touch.


Max R.


Sr. Software Lead

________________________________
From: Claes Redestad <claes.redestad at oracle.com>
Sent: Monday, August 6, 2018 2:20:38 PM
To: mr rupplin; core-libs-dev at openjdk.java.net
Subject: Re: System.java Development Question


Hi Max,

On 2018-08-06 17:55, mr rupplin wrote:

Clases, Hello.


Firstly thank you for replying.  Of course our goal is to show the strengths in the OpenJDK.


Some weeks ago we were working with the ClassFileTransformer as an initial hook for a modest databasing proposal.  We found it to be a dead end.


Of course the company has greenlit further work into the area.  We would like to point out JDK did not have any way to hook the malloc sequence at the time.

it's great that you're showing an interest in the platform and exploring ways to extend/improve it.

It's somewhat coincidental that a lot of work happened in this particular area recently.



Please refer us to the technical lay for the Overhead Heap-Profiling reference you refer to; Ok.

I thought I already had, but it seems I referred to the initial implementation RFE twice. Sorry about that..

The high-level JEP is here: http://openjdk.java.net/jeps/331

It has the high-level overview. From there you can click through to JBS details for the JEP, and from there to the implementation.

For historical reference, initial discussion on the proposal here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-June/017543.html

There were a couple of code reviews done on open lists, but I think this is the final round (and thread): http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023668.html

On top of the Low-Overhead Heap Profiling JEP mentioned, JFR was also open sourced in time for JDK 11. Perhaps it's memory allocation sampling is of interest and a workable alternative.

HTH!

/Claes

From Alan.Bateman at oracle.com  Mon Aug  6 18:44:27 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 Aug 2018 19:44:27 +0100
Subject: Long chains created by direct Buffer::slice
In-Reply-To: <982909B3-AFC1-4FB8-8B78-F558E7AAEE13@oracle.com>
References: <87o9f1n653.fsf@mid.deneb.enyo.de>
 <20180720111559.849741094@eggemoggin.niobe.net>
 <029E054A-7238-4271-AAC5-7904E86DB3D6@oracle.com>
 <87tvolksln.fsf@mid.deneb.enyo.de>
 <04231173-6899-4A4E-BF91-2ACA9AC6B5D4@oracle.com>
 <D1ED57AF-60C8-458E-92CB-1F4EDC0BB2A3@oracle.com>
 <a4047597-9e1b-8384-0f45-1d7155323efc@oracle.com>
 <982909B3-AFC1-4FB8-8B78-F558E7AAEE13@oracle.com>
Message-ID: <4b6f9f1b-c056-d2e6-ead9-48024a8faf4b@oracle.com>

On 06/08/2018 19:13, Paul Sandoz wrote:
> Thanks, i uploaded a new webrev in place that uses a similar technique to some stuff in j.u.concurrent tests.
>
>
The update looks good to me.

-Alan

From joe.darcy at oracle.com  Mon Aug  6 19:11:26 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 6 Aug 2018 12:11:26 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID
 fields in interfaces
Message-ID: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>

Hello,

Various interfaces in the JDK extend Serializable and declare 
serialVersionUID fields. Such fields are ineffectual and 
@SuppressWarnings("serial") should be applied to such fields to suppress 
future planned serial lint checks (JDK-8202056).

Most of the affected files are in the security-libs area with a handful 
in RMI and JNDI:

 ??? http://cr.openjdk.java.net/~darcy/8209024.0/

Patch below. I'll fix-up the copyright years before any push.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 
12:04:46.666000999 -0700
+++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 
12:04:46.510000999 -0700
@@ -109,6 +109,7 @@
 ???? * serialization compatibility with a previous
 ???? * version of the class.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 6603384152749567654L;

 ???? /**
--- old/src/java.base/share/classes/java/security/PrivateKey.java 
2018-08-06 12:04:47.062000999 -0700
+++ new/src/java.base/share/classes/java/security/PrivateKey.java 
2018-08-06 12:04:46.914000999 -0700
@@ -64,5 +64,6 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility with a previous version of the class.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 6034044314589513430L;
 ?}
--- old/src/java.base/share/classes/java/security/PublicKey.java 
2018-08-06 12:04:47.454000999 -0700
+++ new/src/java.base/share/classes/java/security/PublicKey.java 
2018-08-06 12:04:47.306000999 -0700
@@ -50,5 +50,6 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility with a previous version of the class.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 7187392471159151072L;
 ?}
--- 
old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
2018-08-06 12:04:47.858000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
2018-08-06 12:04:47.706000999 -0700
@@ -48,6 +48,7 @@
 ???? * serialization compatibility with a previous
 ???? * version of the class.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 7776497482533790279L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
2018-08-06 12:04:48.270000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
2018-08-06 12:04:48.114000999 -0700
@@ -48,6 +48,7 @@
 ???? * serialization compatibility with a previous
 ???? * version of the class.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 1234526332779022332L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
2018-08-06 12:04:48.674000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
2018-08-06 12:04:48.522000999 -0700
@@ -43,6 +43,7 @@
 ???? * The class fingerprint that is set to indicate
 ???? * serialization compatibility.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -7896394956925609184L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
2018-08-06 12:04:49.078000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
2018-08-06 12:04:48.926000999 -0700
@@ -45,6 +45,7 @@
 ???? * The class fingerprint that is set to indicate
 ???? * serialization compatibility.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -3314988629879632826L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
2018-08-06 12:04:49.470000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
2018-08-06 12:04:49.318000999 -0700
@@ -51,6 +51,7 @@
 ????? * serialization compatibility with a previous
 ????? * version of the type.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 618058533534628008L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
2018-08-06 12:04:49.890000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
2018-08-06 12:04:49.726000999 -0700
@@ -46,6 +46,7 @@
 ????? * serialization compatibility with a previous
 ????? * version of the type.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -5682214253527700368L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
2018-08-06 12:04:50.290000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
2018-08-06 12:04:50.146000999 -0700
@@ -45,6 +45,7 @@
 ????? * serialization compatibility with a previous
 ????? * version of the type.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 5187144804936595022L;

 ???? /**
--- 
old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
2018-08-06 12:04:50.706000999 -0700
+++ 
new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
2018-08-06 12:04:50.554000999 -0700
@@ -42,6 +42,7 @@
 ????? * serialization compatibility with a previous
 ????? * version of the type.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -8727434096241101194L;

 ???? /**
--- old/src/java.base/share/classes/javax/crypto/SecretKey.java 
2018-08-06 12:04:51.142000999 -0700
+++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 
2018-08-06 12:04:50.986000999 -0700
@@ -64,5 +64,6 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility since J2SE 1.4.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -4795878709595146952L;
 ?}
--- 
old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
2018-08-06 12:04:51.550000999 -0700
+++ 
new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
2018-08-06 12:04:51.398000999 -0700
@@ -42,6 +42,7 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility since J2SE 1.4.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 2211791113380396553L;

 ???? /**
--- 
old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
2018-08-06 12:04:51.966000999 -0700
+++ 
new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
2018-08-06 12:04:51.810000999 -0700
@@ -42,6 +42,7 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility since J2SE 1.4.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -6628103563352519193L;

 ???? /**
--- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
2018-08-06 12:04:52.390000999 -0700
+++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
2018-08-06 12:04:52.238000999 -0700
@@ -42,6 +42,7 @@
 ????? * The class fingerprint that is set to indicate serialization
 ????? * compatibility since J2SE 1.4.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -1430015993304333921L;

 ???? /**
--- 
old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
2018-08-06 12:04:52.814000999 -0700
+++ 
new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
2018-08-06 12:04:52.658000999 -0700
@@ -44,6 +44,7 @@
 ?@Deprecated
 ?public interface TlsMasterSecret extends SecretKey {

+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? public static final long serialVersionUID = -461748105810469773L;

 ???? /**
--- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 
12:04:53.294000999 -0700
+++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 
12:04:53.126000999 -0700
@@ -64,6 +64,7 @@
 ???? * serialization compatibility with a previous
 ???? * version of the class.
 ???? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -3617482732056931635L;

 ???? /**
--- 
old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
2018-08-06 12:04:53.702000999 -0700
+++ 
new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
2018-08-06 12:04:53.550000999 -0700
@@ -336,5 +336,6 @@
 ???? /**
 ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability.
 ????? */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 8707690322213556804L;
 ?}
--- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
2018-08-06 12:04:54.098000999 -0700
+++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
2018-08-06 12:04:53.942000999 -0700
@@ -39,6 +39,7 @@
 ?public interface RemoteRef extends java.io.Externalizable {

 ???? /** indicate compatibility with JDK 1.1.x version of class. */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = 3632638527362204081L;

 ???? /**
--- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
2018-08-06 12:04:54.494000999 -0700
+++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
2018-08-06 12:04:54.338000999 -0700
@@ -39,6 +39,7 @@
 ?public interface ServerRef extends RemoteRef {

 ???? /** indicate compatibility with JDK 1.1.x version of class. */
+??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
ineffectual
 ???? static final long serialVersionUID = -4557750989390278438L;

 ???? /**




From sean.mullan at oracle.com  Mon Aug  6 19:23:52 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 6 Aug 2018 15:23:52 -0400
Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security
 property
Message-ID: <cc3d2e44-1d83-f4de-096a-6fb5e27e52d1@oracle.com>

After further evaluation of the new jdk.includeInExceptions security 
property originally introduced in JDK-8204233 [1] and further 
generalized in JDK-8207846 [2], I felt that a stronger warning should be 
added to the description of the property alerting the user to the 
potential risks of setting the property. I also added a test to ensure 
that the property was not accidentally turned on by default (mainly to 
catch accidental pushes where the property was left on as part of 
testing, etc).

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/

--Sean

[1] https://bugs.openjdk.java.net/browse/JDK-8204233
[2] https://bugs.openjdk.java.net/browse/JDK-8207846

From brian.burkhalter at oracle.com  Mon Aug  6 19:34:22 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 6 Aug 2018 12:34:22 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
Message-ID: <5834E0A4-240A-4A39-9165-0416265C7849@oracle.com>

Hi Joe,

Looks fine.

Brian

On Aug 6, 2018, at 12:11 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056).
> 
> Most of the affected files are in the security-libs area with a handful in RMI and JNDI:
> 
>     http://cr.openjdk.java.net/~darcy/8209024.0/
> 
> Patch below. I'll fix-up the copyright years before any push.


From Roger.Riggs at Oracle.com  Mon Aug  6 19:44:44 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 6 Aug 2018 15:44:44 -0400
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
Message-ID: <b7d37b53-7393-ef05-838a-c0eb669a1d5e@Oracle.com>

Hi Joe,

Looks fine.? I would probably have used "ineffective" instead of 
"ineffectual".

(Googling "define ineffective" and "define ineffectual" shows an 
interesting graph of
the use of the term with ineffective growing and ineffectual dropping in 
use.
Look under the more tag)

Regards, Roger


On 8/6/2018 3:11 PM, joe darcy wrote:
> Hello,
>
> Various interfaces in the JDK extend Serializable and declare 
> serialVersionUID fields. Such fields are ineffectual and 
> @SuppressWarnings("serial") should be applied to such fields to 
> suppress future planned serial lint checks (JDK-8202056).
>
> Most of the affected files are in the security-libs area with a 
> handful in RMI and JNDI:
>
> ??? http://cr.openjdk.java.net/~darcy/8209024.0/
>
> Patch below. I'll fix-up the copyright years before any push.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 
> 12:04:46.666000999 -0700
> +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 
> 12:04:46.510000999 -0700
> @@ -109,6 +109,7 @@
> ???? * serialization compatibility with a previous
> ???? * version of the class.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 6603384152749567654L;
>
> ???? /**
> --- old/src/java.base/share/classes/java/security/PrivateKey.java 
> 2018-08-06 12:04:47.062000999 -0700
> +++ new/src/java.base/share/classes/java/security/PrivateKey.java 
> 2018-08-06 12:04:46.914000999 -0700
> @@ -64,5 +64,6 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility with a previous version of the class.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 6034044314589513430L;
> ?}
> --- old/src/java.base/share/classes/java/security/PublicKey.java 
> 2018-08-06 12:04:47.454000999 -0700
> +++ new/src/java.base/share/classes/java/security/PublicKey.java 
> 2018-08-06 12:04:47.306000999 -0700
> @@ -50,5 +50,6 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility with a previous version of the class.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 7187392471159151072L;
> ?}
> --- 
> old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
> 2018-08-06 12:04:47.858000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
> 2018-08-06 12:04:47.706000999 -0700
> @@ -48,6 +48,7 @@
> ???? * serialization compatibility with a previous
> ???? * version of the class.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 7776497482533790279L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
> 2018-08-06 12:04:48.270000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
> 2018-08-06 12:04:48.114000999 -0700
> @@ -48,6 +48,7 @@
> ???? * serialization compatibility with a previous
> ???? * version of the class.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 1234526332779022332L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
> 2018-08-06 12:04:48.674000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
> 2018-08-06 12:04:48.522000999 -0700
> @@ -43,6 +43,7 @@
> ???? * The class fingerprint that is set to indicate
> ???? * serialization compatibility.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -7896394956925609184L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
> 2018-08-06 12:04:49.078000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
> 2018-08-06 12:04:48.926000999 -0700
> @@ -45,6 +45,7 @@
> ???? * The class fingerprint that is set to indicate
> ???? * serialization compatibility.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -3314988629879632826L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
> 2018-08-06 12:04:49.470000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
> 2018-08-06 12:04:49.318000999 -0700
> @@ -51,6 +51,7 @@
> ????? * serialization compatibility with a previous
> ????? * version of the type.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 618058533534628008L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
> 2018-08-06 12:04:49.890000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
> 2018-08-06 12:04:49.726000999 -0700
> @@ -46,6 +46,7 @@
> ????? * serialization compatibility with a previous
> ????? * version of the type.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -5682214253527700368L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
> 2018-08-06 12:04:50.290000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
> 2018-08-06 12:04:50.146000999 -0700
> @@ -45,6 +45,7 @@
> ????? * serialization compatibility with a previous
> ????? * version of the type.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 5187144804936595022L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
> 2018-08-06 12:04:50.706000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
> 2018-08-06 12:04:50.554000999 -0700
> @@ -42,6 +42,7 @@
> ????? * serialization compatibility with a previous
> ????? * version of the type.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -8727434096241101194L;
>
> ???? /**
> --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 
> 2018-08-06 12:04:51.142000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 
> 2018-08-06 12:04:50.986000999 -0700
> @@ -64,5 +64,6 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility since J2SE 1.4.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -4795878709595146952L;
> ?}
> --- 
> old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
> 2018-08-06 12:04:51.550000999 -0700
> +++ 
> new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
> 2018-08-06 12:04:51.398000999 -0700
> @@ -42,6 +42,7 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility since J2SE 1.4.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 2211791113380396553L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
> 2018-08-06 12:04:51.966000999 -0700
> +++ 
> new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
> 2018-08-06 12:04:51.810000999 -0700
> @@ -42,6 +42,7 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility since J2SE 1.4.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -6628103563352519193L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
> 2018-08-06 12:04:52.390000999 -0700
> +++ 
> new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
> 2018-08-06 12:04:52.238000999 -0700
> @@ -42,6 +42,7 @@
> ????? * The class fingerprint that is set to indicate serialization
> ????? * compatibility since J2SE 1.4.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -1430015993304333921L;
>
> ???? /**
> --- 
> old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
> 2018-08-06 12:04:52.814000999 -0700
> +++ 
> new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
> 2018-08-06 12:04:52.658000999 -0700
> @@ -44,6 +44,7 @@
> ?@Deprecated
> ?public interface TlsMasterSecret extends SecretKey {
>
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? public static final long serialVersionUID = -461748105810469773L;
>
> ???? /**
> --- old/src/java.naming/share/classes/javax/naming/Name.java 
> 2018-08-06 12:04:53.294000999 -0700
> +++ new/src/java.naming/share/classes/javax/naming/Name.java 
> 2018-08-06 12:04:53.126000999 -0700
> @@ -64,6 +64,7 @@
> ???? * serialization compatibility with a previous
> ???? * version of the class.
> ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -3617482732056931635L;
>
> ???? /**
> --- 
> old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
> 2018-08-06 12:04:53.702000999 -0700
> +++ 
> new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
> 2018-08-06 12:04:53.550000999 -0700
> @@ -336,5 +336,6 @@
> ???? /**
> ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability.
> ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 8707690322213556804L;
> ?}
> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
> 2018-08-06 12:04:54.098000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
> 2018-08-06 12:04:53.942000999 -0700
> @@ -39,6 +39,7 @@
> ?public interface RemoteRef extends java.io.Externalizable {
>
> ???? /** indicate compatibility with JDK 1.1.x version of class. */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = 3632638527362204081L;
>
> ???? /**
> --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
> 2018-08-06 12:04:54.494000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
> 2018-08-06 12:04:54.338000999 -0700
> @@ -39,6 +39,7 @@
> ?public interface ServerRef extends RemoteRef {
>
> ???? /** indicate compatibility with JDK 1.1.x version of class. */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
> is ineffectual
> ???? static final long serialVersionUID = -4557750989390278438L;
>
> ???? /**
>
>
>


From sean.mullan at oracle.com  Mon Aug  6 19:49:39 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 6 Aug 2018 15:49:39 -0400
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
Message-ID: <5cb5ec06-ad7c-594a-6514-662cec207ad5@oracle.com>

Looks fine to me.

--Sean

On 8/6/18 3:11 PM, joe darcy wrote:
> Hello,
> 
> Various interfaces in the JDK extend Serializable and declare 
> serialVersionUID fields. Such fields are ineffectual and 
> @SuppressWarnings("serial") should be applied to such fields to suppress 
> future planned serial lint checks (JDK-8202056).
> 
> Most of the affected files are in the security-libs area with a handful 
> in RMI and JNDI:
> 
>  ??? http://cr.openjdk.java.net/~darcy/8209024.0/
> 
> Patch below. I'll fix-up the copyright years before any push.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 
> 12:04:46.666000999 -0700
> +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 
> 12:04:46.510000999 -0700
> @@ -109,6 +109,7 @@
>  ???? * serialization compatibility with a previous
>  ???? * version of the class.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 6603384152749567654L;
> 
>  ???? /**
> --- old/src/java.base/share/classes/java/security/PrivateKey.java 
> 2018-08-06 12:04:47.062000999 -0700
> +++ new/src/java.base/share/classes/java/security/PrivateKey.java 
> 2018-08-06 12:04:46.914000999 -0700
> @@ -64,5 +64,6 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility with a previous version of the class.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 6034044314589513430L;
>  ?}
> --- old/src/java.base/share/classes/java/security/PublicKey.java 
> 2018-08-06 12:04:47.454000999 -0700
> +++ new/src/java.base/share/classes/java/security/PublicKey.java 
> 2018-08-06 12:04:47.306000999 -0700
> @@ -50,5 +50,6 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility with a previous version of the class.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 7187392471159151072L;
>  ?}
> --- 
> old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
> 2018-08-06 12:04:47.858000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
> 2018-08-06 12:04:47.706000999 -0700
> @@ -48,6 +48,7 @@
>  ???? * serialization compatibility with a previous
>  ???? * version of the class.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 7776497482533790279L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
> 2018-08-06 12:04:48.270000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
> 2018-08-06 12:04:48.114000999 -0700
> @@ -48,6 +48,7 @@
>  ???? * serialization compatibility with a previous
>  ???? * version of the class.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 1234526332779022332L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
> 2018-08-06 12:04:48.674000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
> 2018-08-06 12:04:48.522000999 -0700
> @@ -43,6 +43,7 @@
>  ???? * The class fingerprint that is set to indicate
>  ???? * serialization compatibility.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -7896394956925609184L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 
> 12:04:49.078000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 
> 12:04:48.926000999 -0700
> @@ -45,6 +45,7 @@
>  ???? * The class fingerprint that is set to indicate
>  ???? * serialization compatibility.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -3314988629879632826L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
> 2018-08-06 12:04:49.470000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
> 2018-08-06 12:04:49.318000999 -0700
> @@ -51,6 +51,7 @@
>  ????? * serialization compatibility with a previous
>  ????? * version of the type.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 618058533534628008L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
> 2018-08-06 12:04:49.890000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
> 2018-08-06 12:04:49.726000999 -0700
> @@ -46,6 +46,7 @@
>  ????? * serialization compatibility with a previous
>  ????? * version of the type.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -5682214253527700368L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
> 2018-08-06 12:04:50.290000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
> 2018-08-06 12:04:50.146000999 -0700
> @@ -45,6 +45,7 @@
>  ????? * serialization compatibility with a previous
>  ????? * version of the type.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 5187144804936595022L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
> 2018-08-06 12:04:50.706000999 -0700
> +++ 
> new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
> 2018-08-06 12:04:50.554000999 -0700
> @@ -42,6 +42,7 @@
>  ????? * serialization compatibility with a previous
>  ????? * version of the type.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -8727434096241101194L;
> 
>  ???? /**
> --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 
> 2018-08-06 12:04:51.142000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 
> 2018-08-06 12:04:50.986000999 -0700
> @@ -64,5 +64,6 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility since J2SE 1.4.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -4795878709595146952L;
>  ?}
> --- 
> old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 
> 12:04:51.550000999 -0700
> +++ 
> new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 
> 12:04:51.398000999 -0700
> @@ -42,6 +42,7 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility since J2SE 1.4.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 2211791113380396553L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
> 2018-08-06 12:04:51.966000999 -0700
> +++ 
> new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
> 2018-08-06 12:04:51.810000999 -0700
> @@ -42,6 +42,7 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility since J2SE 1.4.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -6628103563352519193L;
> 
>  ???? /**
> --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
> 2018-08-06 12:04:52.390000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
> 2018-08-06 12:04:52.238000999 -0700
> @@ -42,6 +42,7 @@
>  ????? * The class fingerprint that is set to indicate serialization
>  ????? * compatibility since J2SE 1.4.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -1430015993304333921L;
> 
>  ???? /**
> --- 
> old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
> 2018-08-06 12:04:52.814000999 -0700
> +++ 
> new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
> 2018-08-06 12:04:52.658000999 -0700
> @@ -44,6 +44,7 @@
>  ?@Deprecated
>  ?public interface TlsMasterSecret extends SecretKey {
> 
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? public static final long serialVersionUID = -461748105810469773L;
> 
>  ???? /**
> --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 
> 12:04:53.294000999 -0700
> +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 
> 12:04:53.126000999 -0700
> @@ -64,6 +64,7 @@
>  ???? * serialization compatibility with a previous
>  ???? * version of the class.
>  ???? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -3617482732056931635L;
> 
>  ???? /**
> --- 
> old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
> 2018-08-06 12:04:53.702000999 -0700
> +++ 
> new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
> 2018-08-06 12:04:53.550000999 -0700
> @@ -336,5 +336,6 @@
>  ???? /**
>  ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability.
>  ????? */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 8707690322213556804L;
>  ?}
> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
> 2018-08-06 12:04:54.098000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
> 2018-08-06 12:04:53.942000999 -0700
> @@ -39,6 +39,7 @@
>  ?public interface RemoteRef extends java.io.Externalizable {
> 
>  ???? /** indicate compatibility with JDK 1.1.x version of class. */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = 3632638527362204081L;
> 
>  ???? /**
> --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
> 2018-08-06 12:04:54.494000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
> 2018-08-06 12:04:54.338000999 -0700
> @@ -39,6 +39,7 @@
>  ?public interface ServerRef extends RemoteRef {
> 
>  ???? /** indicate compatibility with JDK 1.1.x version of class. */
> +??? @SuppressWarnings("serial") // serialVersionUID in an interface is 
> ineffectual
>  ???? static final long serialVersionUID = -4557750989390278438L;
> 
>  ???? /**
> 
> 
> 

From alexandre.iline at oracle.com  Mon Aug  6 20:51:23 2018
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 6 Aug 2018 13:51:23 -0700
Subject: RFR 8208364:
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java missing module
 dependencies declaration	 
Message-ID: <B22F878D-E935-4613-AE0A-A6235F6ADA7E@oracle.com>

Hi,

Please taka a quick look on this fix:

$ hg diff
--- a/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
+++ b/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
@@ -25,8 +25,9 @@
  * @test
  * @bug 8202113
  * @summary Test the caller class loader is not kept strongly reachable
-  *         by reflection API
+ *         by reflection API
  * @library /test/lib/
+ * @modules jdk.compiler
  * @build ReflectionCallerCacheTest Members jdk.test.lib.compiler.CompilerUtils
  * @run testng/othervm ReflectionCallerCacheTest
  */
$

Thank you.

Shura

From joe.darcy at oracle.com  Mon Aug  6 21:30:55 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 6 Aug 2018 14:30:55 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <b7d37b53-7393-ef05-838a-c0eb669a1d5e@Oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
 <b7d37b53-7393-ef05-838a-c0eb669a1d5e@Oracle.com>
Message-ID: <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com>

Hi Roger,

Even if currently less commonly used, I think "ineffectual" better 
captures the intention of what I want to convey in the comment than 
"ineffective."

Thanks all for the reviews; cheers,

-Joe


On 8/6/2018 12:44 PM, Roger Riggs wrote:
> Hi Joe,
>
> Looks fine.? I would probably have used "ineffective" instead of 
> "ineffectual".
>
> (Googling "define ineffective" and "define ineffectual" shows an 
> interesting graph of
> the use of the term with ineffective growing and ineffectual dropping 
> in use.
> Look under the more tag)
>
> Regards, Roger
>
>
> On 8/6/2018 3:11 PM, joe darcy wrote:
>> Hello,
>>
>> Various interfaces in the JDK extend Serializable and declare 
>> serialVersionUID fields. Such fields are ineffectual and 
>> @SuppressWarnings("serial") should be applied to such fields to 
>> suppress future planned serial lint checks (JDK-8202056).
>>
>> Most of the affected files are in the security-libs area with a 
>> handful in RMI and JNDI:
>>
>> ??? http://cr.openjdk.java.net/~darcy/8209024.0/
>>
>> Patch below. I'll fix-up the copyright years before any push.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 
>> 12:04:46.666000999 -0700
>> +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 
>> 12:04:46.510000999 -0700
>> @@ -109,6 +109,7 @@
>> ???? * serialization compatibility with a previous
>> ???? * version of the class.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 6603384152749567654L;
>>
>> ???? /**
>> --- old/src/java.base/share/classes/java/security/PrivateKey.java 
>> 2018-08-06 12:04:47.062000999 -0700
>> +++ new/src/java.base/share/classes/java/security/PrivateKey.java 
>> 2018-08-06 12:04:46.914000999 -0700
>> @@ -64,5 +64,6 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility with a previous version of the class.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 6034044314589513430L;
>> ?}
>> --- old/src/java.base/share/classes/java/security/PublicKey.java 
>> 2018-08-06 12:04:47.454000999 -0700
>> +++ new/src/java.base/share/classes/java/security/PublicKey.java 
>> 2018-08-06 12:04:47.306000999 -0700
>> @@ -50,5 +50,6 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility with a previous version of the class.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 7187392471159151072L;
>> ?}
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
>> 2018-08-06 12:04:47.858000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 
>> 2018-08-06 12:04:47.706000999 -0700
>> @@ -48,6 +48,7 @@
>> ???? * serialization compatibility with a previous
>> ???? * version of the class.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 7776497482533790279L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
>> 2018-08-06 12:04:48.270000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 
>> 2018-08-06 12:04:48.114000999 -0700
>> @@ -48,6 +48,7 @@
>> ???? * serialization compatibility with a previous
>> ???? * version of the class.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 1234526332779022332L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
>> 2018-08-06 12:04:48.674000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 
>> 2018-08-06 12:04:48.522000999 -0700
>> @@ -43,6 +43,7 @@
>> ???? * The class fingerprint that is set to indicate
>> ???? * serialization compatibility.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -7896394956925609184L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
>> 2018-08-06 12:04:49.078000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 
>> 2018-08-06 12:04:48.926000999 -0700
>> @@ -45,6 +45,7 @@
>> ???? * The class fingerprint that is set to indicate
>> ???? * serialization compatibility.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -3314988629879632826L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
>> 2018-08-06 12:04:49.470000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 
>> 2018-08-06 12:04:49.318000999 -0700
>> @@ -51,6 +51,7 @@
>> ????? * serialization compatibility with a previous
>> ????? * version of the type.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 618058533534628008L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
>> 2018-08-06 12:04:49.890000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 
>> 2018-08-06 12:04:49.726000999 -0700
>> @@ -46,6 +46,7 @@
>> ????? * serialization compatibility with a previous
>> ????? * version of the type.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -5682214253527700368L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
>> 2018-08-06 12:04:50.290000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 
>> 2018-08-06 12:04:50.146000999 -0700
>> @@ -45,6 +45,7 @@
>> ????? * serialization compatibility with a previous
>> ????? * version of the type.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 5187144804936595022L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
>> 2018-08-06 12:04:50.706000999 -0700
>> +++ 
>> new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 
>> 2018-08-06 12:04:50.554000999 -0700
>> @@ -42,6 +42,7 @@
>> ????? * serialization compatibility with a previous
>> ????? * version of the type.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -8727434096241101194L;
>>
>> ???? /**
>> --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 
>> 2018-08-06 12:04:51.142000999 -0700
>> +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 
>> 2018-08-06 12:04:50.986000999 -0700
>> @@ -64,5 +64,6 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility since J2SE 1.4.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -4795878709595146952L;
>> ?}
>> --- 
>> old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
>> 2018-08-06 12:04:51.550000999 -0700
>> +++ 
>> new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 
>> 2018-08-06 12:04:51.398000999 -0700
>> @@ -42,6 +42,7 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility since J2SE 1.4.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 2211791113380396553L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
>> 2018-08-06 12:04:51.966000999 -0700
>> +++ 
>> new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 
>> 2018-08-06 12:04:51.810000999 -0700
>> @@ -42,6 +42,7 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility since J2SE 1.4.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -6628103563352519193L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
>> 2018-08-06 12:04:52.390000999 -0700
>> +++ 
>> new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 
>> 2018-08-06 12:04:52.238000999 -0700
>> @@ -42,6 +42,7 @@
>> ????? * The class fingerprint that is set to indicate serialization
>> ????? * compatibility since J2SE 1.4.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -1430015993304333921L;
>>
>> ???? /**
>> --- 
>> old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
>> 2018-08-06 12:04:52.814000999 -0700
>> +++ 
>> new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 
>> 2018-08-06 12:04:52.658000999 -0700
>> @@ -44,6 +44,7 @@
>> ?@Deprecated
>> ?public interface TlsMasterSecret extends SecretKey {
>>
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? public static final long serialVersionUID = -461748105810469773L;
>>
>> ???? /**
>> --- old/src/java.naming/share/classes/javax/naming/Name.java 
>> 2018-08-06 12:04:53.294000999 -0700
>> +++ new/src/java.naming/share/classes/javax/naming/Name.java 
>> 2018-08-06 12:04:53.126000999 -0700
>> @@ -64,6 +64,7 @@
>> ???? * serialization compatibility with a previous
>> ???? * version of the class.
>> ???? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -3617482732056931635L;
>>
>> ???? /**
>> --- 
>> old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
>> 2018-08-06 12:04:53.702000999 -0700
>> +++ 
>> new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 
>> 2018-08-06 12:04:53.550000999 -0700
>> @@ -336,5 +336,6 @@
>> ???? /**
>> ????? * Use serialVersionUID from JNDI 1.1.1 for interoperability.
>> ????? */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 8707690322213556804L;
>> ?}
>> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
>> 2018-08-06 12:04:54.098000999 -0700
>> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 
>> 2018-08-06 12:04:53.942000999 -0700
>> @@ -39,6 +39,7 @@
>> ?public interface RemoteRef extends java.io.Externalizable {
>>
>> ???? /** indicate compatibility with JDK 1.1.x version of class. */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = 3632638527362204081L;
>>
>> ???? /**
>> --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
>> 2018-08-06 12:04:54.494000999 -0700
>> +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 
>> 2018-08-06 12:04:54.338000999 -0700
>> @@ -39,6 +39,7 @@
>> ?public interface ServerRef extends RemoteRef {
>>
>> ???? /** indicate compatibility with JDK 1.1.x version of class. */
>> +??? @SuppressWarnings("serial") // serialVersionUID in an interface 
>> is ineffectual
>> ???? static final long serialVersionUID = -4557750989390278438L;
>>
>> ???? /**
>>
>>
>>
>


From mandy.chung at oracle.com  Mon Aug  6 22:10:22 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 6 Aug 2018 15:10:22 -0700
Subject: RFR 8208364:
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java missing module
 dependencies declaration
In-Reply-To: <B22F878D-E935-4613-AE0A-A6235F6ADA7E@oracle.com>
References: <B22F878D-E935-4613-AE0A-A6235F6ADA7E@oracle.com>
Message-ID: <d3a83911-e90c-7adb-24e0-244110d3aa04@oracle.com>

+1

Mandy

On 8/6/18 1:51 PM, Alexandre (Shura) Iline wrote:
> Hi,
> 
> Please taka a quick look on this fix:
> 
> $ hg diff
> --- a/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
> +++ b/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
> @@ -25,8 +25,9 @@
>    * @test
>    * @bug 8202113
>    * @summary Test the caller class loader is not kept strongly reachable
> -  *         by reflection API
> + *         by reflection API
>    * @library /test/lib/
> + * @modules jdk.compiler
>    * @build ReflectionCallerCacheTest Members jdk.test.lib.compiler.CompilerUtils
>    * @run testng/othervm ReflectionCallerCacheTest
>    */
> $
> 
> Thank you.
> 
> Shura
> 

From lance.andersen at oracle.com  Mon Aug  6 22:11:35 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Aug 2018 18:11:35 -0400
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
Message-ID: <B31D597F-6593-418A-AF90-C79E5F24ABD3@oracle.com>

+1
> On Aug 6, 2018, at 3:11 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056).
> 
> Most of the affected files are in the security-libs area with a handful in RMI and JNDI:
> 
>     http://cr.openjdk.java.net/~darcy/8209024.0/
> 
> Patch below. I'll fix-up the copyright years before any push.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700
> +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.510000999 -0700
> @@ -109,6 +109,7 @@
>      * serialization compatibility with a previous
>      * version of the class.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 6603384152749567654L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700
> +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700
> @@ -64,5 +64,6 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility with a previous version of the class.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 6034044314589513430L;
>  }
> --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700
> +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700
> @@ -50,5 +50,6 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility with a previous version of the class.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 7187392471159151072L;
>  }
> --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700
> @@ -48,6 +48,7 @@
>      * serialization compatibility with a previous
>      * version of the class.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 7776497482533790279L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.270000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700
> @@ -48,6 +48,7 @@
>      * serialization compatibility with a previous
>      * version of the class.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 1234526332779022332L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700
> @@ -43,6 +43,7 @@
>      * The class fingerprint that is set to indicate
>      * serialization compatibility.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -7896394956925609184L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700
> @@ -45,6 +45,7 @@
>      * The class fingerprint that is set to indicate
>      * serialization compatibility.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -3314988629879632826L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.470000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700
> @@ -51,6 +51,7 @@
>       * serialization compatibility with a previous
>       * version of the type.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 618058533534628008L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.890000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700
> @@ -46,6 +46,7 @@
>       * serialization compatibility with a previous
>       * version of the type.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -5682214253527700368L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.290000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.146000999 -0700
> @@ -45,6 +45,7 @@
>       * serialization compatibility with a previous
>       * version of the type.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 5187144804936595022L;
> 
>      /**
> --- old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.706000999 -0700
> +++ new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.554000999 -0700
> @@ -42,6 +42,7 @@
>       * serialization compatibility with a previous
>       * version of the type.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -8727434096241101194L;
> 
>      /**
> --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:51.142000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:50.986000999 -0700
> @@ -64,5 +64,6 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility since J2SE 1.4.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -4795878709595146952L;
>  }
> --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.550000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.398000999 -0700
> @@ -42,6 +42,7 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility since J2SE 1.4.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 2211791113380396553L;
> 
>      /**
> --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.966000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.810000999 -0700
> @@ -42,6 +42,7 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility since J2SE 1.4.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -6628103563352519193L;
> 
>      /**
> --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.390000999 -0700
> +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.238000999 -0700
> @@ -42,6 +42,7 @@
>       * The class fingerprint that is set to indicate serialization
>       * compatibility since J2SE 1.4.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -1430015993304333921L;
> 
>      /**
> --- old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.814000999 -0700
> +++ new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.658000999 -0700
> @@ -44,6 +44,7 @@
>  @Deprecated
>  public interface TlsMasterSecret extends SecretKey {
> 
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      public static final long serialVersionUID = -461748105810469773L;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.294000999 -0700
> +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.126000999 -0700
> @@ -64,6 +64,7 @@
>      * serialization compatibility with a previous
>      * version of the class.
>      */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -3617482732056931635L;
> 
>      /**
> --- old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.702000999 -0700
> +++ new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.550000999 -0700
> @@ -336,5 +336,6 @@
>      /**
>       * Use serialVersionUID from JNDI 1.1.1 for interoperability.
>       */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 8707690322213556804L;
>  }
> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:54.098000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:53.942000999 -0700
> @@ -39,6 +39,7 @@
>  public interface RemoteRef extends java.io.Externalizable {
> 
>      /** indicate compatibility with JDK 1.1.x version of class. */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = 3632638527362204081L;
> 
>      /**
> --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.494000999 -0700
> +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.338000999 -0700
> @@ -39,6 +39,7 @@
>  public interface ServerRef extends RemoteRef {
> 
>      /** indicate compatibility with JDK 1.1.x version of class. */
> +    @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual
>      static final long serialVersionUID = -4557750989390278438L;
> 
>      /**
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From jonathan.gibbons at oracle.com  Mon Aug  6 22:19:43 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 06 Aug 2018 15:19:43 -0700
Subject: RFR 8208364:
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
 missing module dependencies declaration
In-Reply-To: <d3a83911-e90c-7adb-24e0-244110d3aa04@oracle.com>
References: <B22F878D-E935-4613-AE0A-A6235F6ADA7E@oracle.com>
 <d3a83911-e90c-7adb-24e0-244110d3aa04@oracle.com>
Message-ID: <5B68C97F.6020409@oracle.com>

You might check the indentation of the modified lines.

-- Jon

On 08/06/2018 03:10 PM, mandy chung wrote:
> +1
>
> Mandy
>
> On 8/6/18 1:51 PM, Alexandre (Shura) Iline wrote:
>> Hi,
>>
>> Please taka a quick look on this fix:
>>
>> $ hg diff
>> --- 
>> a/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
>> +++ 
>> b/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
>> @@ -25,8 +25,9 @@
>>    * @test
>>    * @bug 8202113
>>    * @summary Test the caller class loader is not kept strongly 
>> reachable
>> -  *         by reflection API
>> + *         by reflection API
>>    * @library /test/lib/
>> + * @modules jdk.compiler
>>    * @build ReflectionCallerCacheTest Members 
>> jdk.test.lib.compiler.CompilerUtils
>>    * @run testng/othervm ReflectionCallerCacheTest
>>    */
>> $
>>
>> Thank you.
>>
>> Shura
>>


From alexandre.iline at oracle.com  Mon Aug  6 22:22:28 2018
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 6 Aug 2018 15:22:28 -0700
Subject: RFR 8208364:
 java/lang/reflect/callerCache/ReflectionCallerCacheTest.java missing module
 dependencies declaration
In-Reply-To: <5B68C97F.6020409@oracle.com>
References: <B22F878D-E935-4613-AE0A-A6235F6ADA7E@oracle.com>
 <d3a83911-e90c-7adb-24e0-244110d3aa04@oracle.com>
 <5B68C97F.6020409@oracle.com>
Message-ID: <203A2D1A-3727-488D-B462-81DA59FFF4D4@oracle.com>

There was extra space before the star in "by reflection API? line. I have removed it.

-  *         by reflection API
+ *         by reflection API

> On Aug 6, 2018, at 3:19 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> You might check the indentation of the modified lines.
> 
> -- Jon
> 
> On 08/06/2018 03:10 PM, mandy chung wrote:
>> +1
>> 
>> Mandy
>> 
>> On 8/6/18 1:51 PM, Alexandre (Shura) Iline wrote:
>>> Hi,
>>> 
>>> Please taka a quick look on this fix:
>>> 
>>> $ hg diff
>>> --- a/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
>>> +++ b/test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
>>> @@ -25,8 +25,9 @@
>>>   * @test
>>>   * @bug 8202113
>>>   * @summary Test the caller class loader is not kept strongly reachable
>>> -  *         by reflection API
>>> + *         by reflection API
>>>   * @library /test/lib/
>>> + * @modules jdk.compiler
>>>   * @build ReflectionCallerCacheTest Members jdk.test.lib.compiler.CompilerUtils
>>>   * @run testng/othervm ReflectionCallerCacheTest
>>>   */
>>> $
>>> 
>>> Thank you.
>>> 
>>> Shura
>>> 
> 


From Sergey.Bylokhov at oracle.com  Mon Aug  6 22:39:38 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 6 Aug 2018 15:39:38 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
 <b7d37b53-7393-ef05-838a-c0eb669a1d5e@Oracle.com>
 <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com>
Message-ID: <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com>

Hi, Joe.

On 06/08/2018 14:30, joe darcy wrote:
> Even if currently less commonly used, I think "ineffectual" better 
> captures the intention of what I want to convey in the comment than 
> "ineffective."

Can you please clarify this: what does it mean "ineffectual" in this 
context? why we need to "suppress" them and why these fields cannot be 
dropped?



-- 
Best regards, Sergey.

From joe.darcy at oracle.com  Mon Aug  6 23:16:45 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 6 Aug 2018 16:16:45 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
 <b7d37b53-7393-ef05-838a-c0eb669a1d5e@Oracle.com>
 <6347a324-3aaa-a4ec-9e1d-1083456ddf37@oracle.com>
 <60dc4d93-64a3-9162-e51b-15b7a86b2272@oracle.com>
Message-ID: <167d903a-b3a0-19bb-b442-41463aa64962@oracle.com>

Hi Sergey,

On 8/6/2018 3:39 PM, Sergey Bylokhov wrote:
> Hi, Joe.
>
> On 06/08/2018 14:30, joe darcy wrote:
>> Even if currently less commonly used, I think "ineffectual" better 
>> captures the intention of what I want to convey in the comment than 
>> "ineffective."
>
> Can you please clarify this: what does it mean "ineffectual" in this 
> context? why we need to "suppress" them and why these fields cannot be 
> dropped?
>

A serialVersionUID field is intended to be used to provide the serial 
hash of a class both to avoid the cost of its computation at runtime and 
to provide cross-version serial stability in the face of innocuous 
changes to the class. The serialVersionUID of an interface type is *not* 
used in the serialization machinery. The names of interfaces are used 
however. Therefore, a serialVersionUID field on an interface does not 
have the effect one would assume it has, namely altering the behavior of 
serialization. In that sense, these field declarations in interfaces are 
ineffectual.

I'm working on expanding the checks done by "javac -Xlint:serial", 
including flagging these and other ineffectual serialization coding 
patterns. I've pushed a number of related cleanup fixes earlier in JDK 
12 (JDK-8208060, JDK-8207751, JDK-8208782, etc.). Much of the JDK code 
base is compiled using "-Xlint:all -Werror", meaning that if the set of 
checks is expanded and new warnings are generated, the build will fail. 
While it would be possible to exclude the expanded serial check from the 
build, I'd prefer to address the serial issues instead.

Since the files modified by? JDK-8209024 are pre-JDK 9 interfaces, their 
static serialVersionUID fields are *public* fields, meaning they are 
part of the interfaces' contract. Therefore, the fieldscannot just be 
removed per our usual compatibility policy, unlike, say a private field 
in a class. For that reason, I think it is reasonable to suppress the 
(future) serial warnings for these fields, rather than to remove the 
fields. I wouldn't oppose the effort if someone else wanted to 
deprecated these fields for removal and then remove the fields in a 
future release, but I don't think the cost/benefit of that particular 
route is justified.

HTH,

-Joe


From david.holmes at oracle.com  Tue Aug  7 01:44:34 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Aug 2018 11:44:34 +1000
Subject: Core Type Compilation Issues
In-Reply-To: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <5771992d-ef16-b92b-0985-0cfe00ea724c@oracle.com>

Hi Max,

I can give you some guidance but no quick fixes ...

On 7/08/2018 4:21 AM, mr rupplin wrote:
> Three problems that I run into when running the 'make jdk' after minor work on the System.java class for JNI and custom JDK:
> 
> java/lang/memory/GroupListener.java:111: warning: [rawtypes] found raw type: Class
>          Class basetype = null;

You are using a raw type - hence the warning. If you don't know what a 
raw type is then you need to do a refresher on Java's generic types. Fix 
is to not use a raw type e.g.:

Class<?> baseType = null;

but it will also depend on how baseType is used.

> java/lang/memory/GroupListener.java:7: error: package java.rmi does not exist
> import java.rmi.Remote;

In OpenJDK 9 you are using the new modular JDK. All of the core packages 
in java.lang are in the java.base module. The java.rmi package is in the 
java.rmi module. The base module, by design, can not have any 
dependencies on any other module - as all other modules implicitly 
depend on the base module. So while you would normally fix this by 
telling the javac compiler to consider the java.rmi module (sorry not 
sure exact flags to use) in this case I don't think you have that 
option. It may be easier to define your custom classes in a different 
package, ie in javax.lang.memory, outside of the base module.

> java/lang/memory/GroupListener.java:13: warning: [exports] class Group in module java.base is not accessible to clients that require this module
>          public final ArrayList<Group> groups = new ArrayList<Group>();

When you add new packages to a module that you need other code to be 
able to access from outside the module, you have to update the 
module-info.java file, for that module, to export those packages.

David
-----

> 
> 
> == ==
> 
> 
> Can we get explanations for each of these?  Also the solutions or workarounds.  OkQ!
> 
> 
> Thanks,
> 
> 
> Max R.
> 
> 
> Software Lead
> 

From iris.clark at oracle.com  Tue Aug  7 03:21:21 2018
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 6 Aug 2018 20:21:21 -0700 (PDT)
Subject: RFR (XXS) 8201394: Update java.se module summary to reflect removal
 of java.se.ee module
Message-ID: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>

Hi.

Please review the following minor change to update the java.se
module summary.

    8201394:  Update java.se module summary to reflect removal of java.se.ee module
    https://bugs.openjdk.java.net/browse/JDK-8201394

In JDK 10, we had the following module summaries:

    java.base - Defines the foundational APIs of the Java SE Platform
    java.se - Defines the core Java SE API.
    java.se.ee - Defines the full API of the Java SE Platform

Now that the java.se.ee module has been removed, the description of
the java.se module summary should be changed to reflect the fact that
it is the embodiment of the SE API.  Our module summaries will be
as follows:

    java.base - Defines the foundational APIs of the Java SE Platform [no change]
    java.se - Defines the API of the Java SE Platform

This is the diff:

diff -r 331888ea4a78 src/java.se/share/classes/module-info.java
--- a/src/java.se/share/classes/module-info.java        Tue Jul 31 14:04:29 2018 -0700
+++ b/src/java.se/share/classes/module-info.java        Mon Aug 06 
14:53:37 2018 -0700
@@ -24,7 +24,7 @@
  */

 /**
- * Defines the core Java SE API.
+ * Defines the API of the Java SE Platform.
  * <P>
  *
  * <dl>

Thanks,
iris

From xu.y.yin at oracle.com  Tue Aug  7 03:53:17 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 7 Aug 2018 11:53:17 +0800
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <a8609400-6797-dd5c-ca1f-e045998f2d59@Oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
 <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
 <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>
 <a8609400-6797-dd5c-ca1f-e045998f2d59@Oracle.com>
Message-ID: <8F1354FE-BD3F-47CA-84CB-73B996B36FAD@oracle.com>

Hi, Roger

Thanks a lot for your review and comments, inline and updated webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208279/webrev.03/

> On 6 Aug 2018, at 10:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Chris,
> 
> EnvTestBase.java:  The class and each of the methods should have javadoc with a descriptive comment
> to make the test construction easier to understand for future maintenance especially since
> they are shared/overridden and used by many of the test cases.
> For example, verifyEnvProperty should say what is true about a valid property.
> With many layers of inherited test methods it needs easier to understand what comes from where.
> Build good habits with writing complete sentences with capitalization and punctuation in comments.

Sure, I added javadoc to EnvTestBase class and shared/override methods (except getter/setter), will also complement javadoc to test base class in other review thread, thanks

> 
> initContext() belongs in DNSTestBase along with context() and setContext() to avoid splitting that
> function across multiple classes.
> Or remove initContext() since it is overridden in several tests (without calling super) and
> just call setContext() with new InitialDirContext(env()) consistently in each test.

Yep, I hesitated at first whether put initContext() to DNSTestBase, after look through many dns test cases, I found there are a lot of tests may need to override it and some case to use parameterized method will be easier (such as initContext(String, String) used in Factory Tests), so I decided to leave it to each sub test base or tests to customize. Anyway we could refactor it later if we found that way better.
For now I removed initContext() from EnvTestBase as you suggested in 2nd and used private initContext() for complex initialization or just call setContext with new InitialDirContext(env()) for simple one, thanks

> 
> ProviderUrlGen.java should not mention SWAN by name as it is an internal resource
> (and that's not the current name).

Sure, removed that name

> 
> RemoveInherited.java: for strings that need to be consistent across the test, they should be defined as
> final statics so there is only one declaration.

Fixed as your suggested

Thanks & Regards,
Chris

> 
> Thanks, Roger
> 
> On 8/6/2018 3:09 AM, Chris Yin wrote:
>> Thank you, Vyom
>> 
>> Regards,
>> Chris
>> 
>>> On 6 Aug 2018, at 2:02 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Latest webrev looks good to me.
>>> 
>>> Thanks,
>>> 
>>> Vyom
>>> 
>>> 
>>> On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
>>>> Hi, Vyom
>>>> 
>>>> Thank a lot for your review and comments, inline and update new webrev as below
>>>> 
>>>> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/
>>>> 
>>>>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> Overall looks good to me, couple of minor comment.
>>>>> 
>>>>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
>>>> Fixed, thanks
>>>> 
>>>>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
>>>> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>>>> 
>>>> Thanks,
>>>> Chris
>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Vyom
>>>>> 
>>>>> 
>>>>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>>>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>>>> 
>>>>>> Regards,
>>>>>> Chris
>>>>>> 
>>>>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>>>> 
>>>>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>>>> 
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Chris
> 


From xu.y.yin at oracle.com  Tue Aug  7 04:00:08 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 7 Aug 2018 12:00:08 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <bb23b246-8240-0a95-85ac-4e8d291b13dd@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <bb23b246-8240-0a95-85ac-4e8d291b13dd@oracle.com>
Message-ID: <A2482655-9405-4439-9F9A-03686DECC79C@oracle.com>

Got it, thank you Vyom, and I added some javadoc to LookupFactoryBase (per comments from another thread) in new webrev as below

http://cr.openjdk.java.net/~xyin/8208483/webrev.02/

Thanks & Regards,
Chris

> On 6 Aug 2018, at 8:38 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> 
> 
> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>> Hi, Vyom
>> 
>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>> 
>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>> 
>> Paste a few javadoc here against ?getObjectInstance? method as below
>> 
>> * @return The object created; null if an object cannot be created.
>> * @exception Exception If this object factory encountered an exception
>> * while attempting to create an object, and no other object factories are
>> * to be tried.
> Yes you are right, we have to live with null.
> 
> Vyom
>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>> Same as above
>> 
>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>> 
>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>> 
>> Thanks & Regards,
>> Chris
>> 
>>> Thanks,
>>> 
>>> Vyom
>>> 
>>> 
>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>> 
>>>> Regards,
>>>> Chris


From amaembo at gmail.com  Tue Aug  7 05:52:54 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 7 Aug 2018 12:52:54 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
Message-ID: <CAE+3fjZ09G4307tT70cOHada9iWED5UwCLJ36Fr8rfuxR9MNcw@mail.gmail.com>

Ping! Could you please review and sponsor this changeset?
I updated version tag from since 11 to since 12:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r2/

Thanks in advance!

With best regards,
Tagir Valeev.

On Thu, Jun 21, 2018 at 11:33 AM Tagir Valeev <amaembo at gmail.com> wrote:

> Please review and sponsor:
>
> https://bugs.openjdk.java.net/browse/JDK-8205461
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>
> See also previous discussion thread at [1]. It seems that we did not reach
> the final conclusion about the collector name, so in this review it's still
> named as "pairing" (proposed by me). Other name proposals:
>
> bisecting - by Paul Sandoz (sounds like input is split by two parts like
> in partitioningBy, which is not the case)
> tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical
> operation, while our collector is symmetrical)
> duplex(ing) - by Jacob Glickman (well, probably ok?)
> bifurcate - by James Laskey (or bifurcating?)
> replicator - by James Laskey (as in DNA)
> replicating - by Peter Levart
> fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked
> Wikipedia [2], does not look like suitable)
> distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac;
> but common meaning of "distributing" is different)
> tapping - by Kirk Pepperdine (I have no associations; Google images shows
> some acupuncture procedures)
> split - by Kirk Pepperdine (may be confused with Spliterator)
> unzipping - by John Rose
> biMapping - by Zheka Kozlov (but he also suggests to change signature
> which is unnecessary)
> toBoth - by Peter Levart (but usually toXyz shows target container like
> toArray/toList/toSet, but there's not "Both" container)
> collectionToBothAndThen - by Zheka Kozlov (but too long)
> collectingToBoth - by Zheka Kozlov
> collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a little
> bit repititive?)
> biCollecting - by Zheka Kozlov
> expanding - by Paul Sandoz (doesn't sound very descriptive to me)
> forking - by Victor Williams Stafusa da Silva (could be thought that
> something is parallelized as forking is usually something connected to
> parallel computations)
>
> I think that it's better to concentrate not on the "splitting" part (each
> element is passed to two collectors), but on the "joining" part (results of
> two collectors are combined together). So my preference now is "merging" or
> "combining". If limiting the selection to the suggested options I'd prefer
> "duplexing" or "bifurcating" or to stay with my original version "pairing".
> Of course original Stream API author voices have more weight here, so if
> you insist on particular version, I will follow.
>
> By the way looking into CollectorsTest.java I found some minor things to
> cleanup:
> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced
> with simple `.map(mapper)` and `.flatMap(mapper)` respectively
> 2. In many methods redundant `throws ReflectiveOperationException` is
> declared while exception is never thrown
> 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks useless as
> `map` is already of `Map<Boolean, D>` type, so this check is always false
> (we would never enter this method if it's true). Similarly `if
> (!List.class.isAssignableFrom(value.getClass()))`
> 4. Deprecated `clazz.newInstance()` is used
> 5. Test named `testGroupubgByWithReducing` should be renamed to
> `testGroupingByWithReducing`
>
> Should I fix some or all of these issues? As separate changeset or within
> this one?
>
> With best regards,
> Tagir Valeev.
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html
> [2] https://en.wikipedia.org/wiki/Fan-out
>

From Alan.Bateman at oracle.com  Tue Aug  7 06:12:15 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Aug 2018 07:12:15 +0100
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on
 serialVersionUID fields in interfaces
In-Reply-To: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
Message-ID: <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com>



On 06/08/2018 20:11, joe darcy wrote:
> Hello,
>
> Various interfaces in the JDK extend Serializable and declare 
> serialVersionUID fields. Such fields are ineffectual and 
> @SuppressWarnings("serial") should be applied to such fields to 
> suppress future planned serial lint checks (JDK-8202056).
>
> Most of the affected files are in the security-libs area with a 
> handful in RMI and JNDI:
>
> ??? http://cr.openjdk.java.net/~darcy/8209024.0/
>
> Patch below. I'll fix-up the copyright years before any push.
Is there a follow-on patch coming to deprecate these fields?

-Alan

From Alan.Bateman at oracle.com  Tue Aug  7 06:29:14 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Aug 2018 07:29:14 +0100
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
Message-ID: <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com>

On 06/08/2018 17:49, Daniel D. Daugherty wrote:
> :
>
> +java/net/Socket/LingerTest.java 8208690 generic-all
> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
> +
> ?############################################################################ 
>
Can these tests be changed to /othervm instead of excluding them?

-Alan

From Alan.Bateman at oracle.com  Tue Aug  7 06:27:24 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Aug 2018 07:27:24 +0100
Subject: RFR (XXS) 8201394: Update java.se module summary to reflect
 removal of java.se.ee module
In-Reply-To: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
References: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
Message-ID: <70226bb8-199f-0e88-5d84-0a38eded44fc@oracle.com>

On 07/08/2018 04:21, Iris Clark wrote:
> :
>
> This is the diff:
>
> diff -r 331888ea4a78 src/java.se/share/classes/module-info.java
> --- a/src/java.se/share/classes/module-info.java        Tue Jul 31 14:04:29 2018 -0700
> +++ b/src/java.se/share/classes/module-info.java        Mon Aug 06
> 14:53:37 2018 -0700
> @@ -24,7 +24,7 @@
>    */
>
>   /**
> - * Defines the core Java SE API.
> + * Defines the API of the Java SE Platform.
>    * <P>
>    *
>    * <dl>
>
Looks good.

-Alan

From Alan.Bateman at oracle.com  Tue Aug  7 07:09:35 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Aug 2018 08:09:35 +0100
Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security
 property
In-Reply-To: <cc3d2e44-1d83-f4de-096a-6fb5e27e52d1@oracle.com>
References: <cc3d2e44-1d83-f4de-096a-6fb5e27e52d1@oracle.com>
Message-ID: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com>

On 06/08/2018 20:23, Sean Mullan wrote:
> After further evaluation of the new jdk.includeInExceptions security 
> property originally introduced in JDK-8204233 [1] and further 
> generalized in JDK-8207846 [2], I felt that a stronger warning should 
> be added to the description of the property alerting the user to the 
> potential risks of setting the property. I also added a test to ensure 
> that the property was not accidentally turned on by default (mainly to 
> catch accidental pushes where the property was left on as part of 
> testing, etc).
>
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/
I think it would simpler and read a bit better to just say "Use caution 
before ...", meaning drop "NOTE" and "extra". The rest of the text is 
okay. The additional test looks okay too.

-Alan

From ying.z.zhou at oracle.com  Tue Aug  7 07:31:00 2018
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Tue, 7 Aug 2018 15:31:00 +0800
Subject: [12]RFR 8208656: Move java/util/Calendar/CalendarTestScripts tests
 into OpenJDK
Message-ID: <564a5be8-df5a-69a8-8fb4-9dc2f8015503@oracle.com>

Hello,

Please help review the patch to move some tests to OpenJDK. Thank you!

Bug: https://bugs.openjdk.java.net/browse/JDK-8208656

Webrev: http://cr.openjdk.java.net/~dzhou/8208656/webrev.00/ 
<http://cr.openjdk.java.net/%7Edzhou/8208656/webrev.00/>

Regards,

Daisy


From peter.levart at gmail.com  Tue Aug  7 08:08:41 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Aug 2018 10:08:41 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjZ09G4307tT70cOHada9iWED5UwCLJ36Fr8rfuxR9MNcw@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <CAE+3fjZ09G4307tT70cOHada9iWED5UwCLJ36Fr8rfuxR9MNcw@mail.gmail.com>
Message-ID: <55f690c9-f21b-ee9d-aa30-f838b2da7257@gmail.com>

Hi Tagir,

Unless you have already got a sponsor (can't remember if somebody 
already offered you a sponsorship), I can volunteer.

Regarding the code, I only have one comment about the naming of the last 
parameter: "finisher". To avoid confusion, it would be good to name it 
differently from the Collector's functions. "finisher" and "combiner" 
are already taken by Collector API. You describe the parameter in 
javadoc as "the function which merges two results into the single one". 
So what about "merger" or "result[s]Merger" ?

...and one comment about handling of IDENTITY_FINISH: You correctly 
remove IDENTITY_FINISH from the resulting collector's characteristics, 
but you don't honor the IDENTITY_FINISH characteristics of the two 
parameter collectors. It should work nevertheless, but suppose some 
"sloppy programmed" collector doesn't bother to return the identity 
function when it announces that it has IDENTITY_FINISH characteristic...

Regards, Peter


On 08/07/2018 07:52 AM, Tagir Valeev wrote:
> Ping! Could you please review and sponsor this changeset?
> I updated version tag from since 11 to since 12:
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r2/
>
> Thanks in advance!
>
> With best regards,
> Tagir Valeev.
>
> On Thu, Jun 21, 2018 at 11:33 AM Tagir Valeev <amaembo at gmail.com> wrote:
>
>> Please review and sponsor:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8205461
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>>
>> See also previous discussion thread at [1]. It seems that we did not reach
>> the final conclusion about the collector name, so in this review it's still
>> named as "pairing" (proposed by me). Other name proposals:
>>
>> bisecting - by Paul Sandoz (sounds like input is split by two parts like
>> in partitioningBy, which is not the case)
>> tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical
>> operation, while our collector is symmetrical)
>> duplex(ing) - by Jacob Glickman (well, probably ok?)
>> bifurcate - by James Laskey (or bifurcating?)
>> replicator - by James Laskey (as in DNA)
>> replicating - by Peter Levart
>> fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked
>> Wikipedia [2], does not look like suitable)
>> distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac;
>> but common meaning of "distributing" is different)
>> tapping - by Kirk Pepperdine (I have no associations; Google images shows
>> some acupuncture procedures)
>> split - by Kirk Pepperdine (may be confused with Spliterator)
>> unzipping - by John Rose
>> biMapping - by Zheka Kozlov (but he also suggests to change signature
>> which is unnecessary)
>> toBoth - by Peter Levart (but usually toXyz shows target container like
>> toArray/toList/toSet, but there's not "Both" container)
>> collectionToBothAndThen - by Zheka Kozlov (but too long)
>> collectingToBoth - by Zheka Kozlov
>> collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a little
>> bit repititive?)
>> biCollecting - by Zheka Kozlov
>> expanding - by Paul Sandoz (doesn't sound very descriptive to me)
>> forking - by Victor Williams Stafusa da Silva (could be thought that
>> something is parallelized as forking is usually something connected to
>> parallel computations)
>>
>> I think that it's better to concentrate not on the "splitting" part (each
>> element is passed to two collectors), but on the "joining" part (results of
>> two collectors are combined together). So my preference now is "merging" or
>> "combining". If limiting the selection to the suggested options I'd prefer
>> "duplexing" or "bifurcating" or to stay with my original version "pairing".
>> Of course original Stream API author voices have more weight here, so if
>> you insist on particular version, I will follow.
>>
>> By the way looking into CollectorsTest.java I found some minor things to
>> cleanup:
>> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced
>> with simple `.map(mapper)` and `.flatMap(mapper)` respectively
>> 2. In many methods redundant `throws ReflectiveOperationException` is
>> declared while exception is never thrown
>> 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks useless as
>> `map` is already of `Map<Boolean, D>` type, so this check is always false
>> (we would never enter this method if it's true). Similarly `if
>> (!List.class.isAssignableFrom(value.getClass()))`
>> 4. Deprecated `clazz.newInstance()` is used
>> 5. Test named `testGroupubgByWithReducing` should be renamed to
>> `testGroupingByWithReducing`
>>
>> Should I fix some or all of these issues? As separate changeset or within
>> this one?
>>
>> With best regards,
>> Tagir Valeev.
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html
>> [2] https://en.wikipedia.org/wiki/Fan-out
>>


From vyom.tewari at oracle.com  Tue Aug  7 08:35:19 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Tue, 7 Aug 2018 14:05:19 +0530
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
Message-ID: <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>

Hi Chris,

Overall latest code looks good to me, one minor comment did you consider 
moving? "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in 
"LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp 
inherit "LookupFactoryBase".

.Thanks,

Vyom


On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
> Hi, Vyom
>
> Many thanks for your review and comments, inline and updated webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>
>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>
> Paste a few javadoc here against ?getObjectInstance? method as below
>
> * @return The object created; null if an object cannot be created.
> * @exception Exception If this object factory encountered an exception
> * while attempting to create an object, and no other object factories are
> * to be tried.
>
>> 2-> DirTxtFactory.java same as "DirFactory.java?.
> Same as above
>
>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>
>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>
> Thanks & Regards,
> Chris
>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>
>>> Regards,
>>> Chris


From xu.y.yin at oracle.com  Tue Aug  7 09:41:33 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 7 Aug 2018 17:41:33 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
Message-ID: <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>

Hi, Vyom

Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208483/webrev.03/

Regards,
Chris

> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
> 
> .Thanks,
> 
> Vyom
> 
> 
> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>> Hi, Vyom
>> 
>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>> 
>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>> 
>> Paste a few javadoc here against ?getObjectInstance? method as below
>> 
>> * @return The object created; null if an object cannot be created.
>> * @exception Exception If this object factory encountered an exception
>> * while attempting to create an object, and no other object factories are
>> * to be tried.
>> 
>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>> Same as above
>> 
>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>> 
>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>> 
>> Thanks & Regards,
>> Chris
>> 
>>> Thanks,
>>> 
>>> Vyom
>>> 
>>> 
>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>> 
>>>> Regards,
>>>> Chris
> 


From matthias.baesken at sap.com  Tue Aug  7 10:12:29 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 7 Aug 2018 10:12:29 +0000
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
Message-ID: <da9951b8d7c04210a46a12b0ba43b16d@sap.com>

Hi Brian, small remark from my side ,  looks like you changed in

src/java.base/unix/native/libjava/TimeZone_md.c

src/java.base/unix/native/libjava/childproc.c

and

src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c

at some places  dirent64  /  readdir64   to   dirent  /  readdir
in the linux/solaris  coding.

for example

TimeZone_md.c

122 static char *
123 findZoneinfoFile(char *buf, size_t size, const char *dir)
124 {
125     DIR *dirp = NULL;
126     struct stat statbuf;
127     struct dirent *dp = NULL;.


Was it intended  to  change for linux/solaris ?

Best regards , Matthias


From: Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: Samstag, 4. August 2018 00:08
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: core-libs-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir versus opendir64/closedir64

HI Matthias,

I think I fixed the dirent problem: thanks for pointing it out.

http://cr.openjdk.java.net/~bpb/8207744/webrev.03/

The usual builds passed and tests are running.

I think that there is some _ALLBSD_SOURCE cruft in UnixNativeDispatcher.c which could be cleaned up but we'll leave that for another day.

Thanks,

Brian

On Aug 2, 2018, at 11:57 PM, Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:


looks  like the  function

struct dirent64 *readdir64 (DIR64 *DirectoryPointer);

returns   dirent64*   ( according to https://www.ibm.com/support/knowledgecenter/no/ssw_aix_72/com.ibm.aix.basetrf1/opendir.htm   )

and  some of  the files below  still have  dirent* on AIX  ( at some places it is redefined ).

For example  :

http://cr.openjdk.java.net/~bpb/8207744/webrev.02/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c.frames.html

508 jint unix_getChildren(JNIEnv *env, jlong jpid, jlongArray jarray,
509                       jlongArray jparentArray, jlongArray jstimesArray) {
510     DIR* dir;
511     struct dirent* ptr;


Not sure if this is really an issue  in "real life"  ....


From maurizio.cimadamore at oracle.com  Tue Aug  7 11:21:55 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 7 Aug 2018 12:21:55 +0100
Subject: RFR 8209064: Make intellij support more robust after changes for
 2018.2
Message-ID: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>

Hi,
last week I submitted an 'emergency' patch to fix intellij project 
support after 2018.2 changes. The goal of these changes was to move the 
build.xml ant file out of the .idea folder, as the IDE no longer 
supported DOM indexing in such folders (as a result of 
https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
tweaked the scripts to copy build.xml in the build folder.

Thinking more about this issue, there's a more robust fix possible, 
which doesn't involve moving files to the build folder (which could be 
potentially unreliable, depending on how people build the JDK). In fact, 
the best solution is to leave build.xml where it is, and fix the 
remaining configuration files to point at it. This allows to revert all 
changes in the scripts that set up the project configuration 
(bin/idea.sh for JDK, and make/langtools/build.xml for langtools).

For the langtools project a bit more changes were necessary, given that 
in langtools we did not have a 'template' folder - and all intellij 
files were dumped onto the same path. So I had to move the configuration 
langtools files (all but build.xml) under a new template folder (located 
under make/langtools/intellij/make) and place build.xml outside it. Then 
tweak the build.xml script to work off this new template folder. These 
are all small conceptual changes, but the impact on the webrev is quite 
biggie (because of file renaming etc.).

I also took the chance to fix some issues with the JDK project ANT 
configuration (see changes in make/idea/template/workspace.xml), as the 
last changes did not update the location of the ant file used here - as 
a result no ant target entries were showing up under the Build menu.

Webrev here:

http://cr.openjdk.java.net/~mcimadamore/8209064/

Cheers
Maurizio


From lance.andersen at oracle.com  Tue Aug  7 11:26:13 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Aug 2018 07:26:13 -0400
Subject: RFR (XXS) 8201394: Update java.se module summary to reflect
 removal of java.se.ee module
In-Reply-To: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
References: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
Message-ID: <6F5CA13E-413F-4C91-897E-28FEE7793EB0@oracle.com>

Hi Iris

I think the revised wording is fine


> On Aug 6, 2018, at 11:21 PM, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Please review the following minor change to update the java.se
> module summary.
> 
>    8201394:  Update java.se module summary to reflect removal of java.se.ee module
>    https://bugs.openjdk.java.net/browse/JDK-8201394
> 
> In JDK 10, we had the following module summaries:
> 
>    java.base - Defines the foundational APIs of the Java SE Platform
>    java.se - Defines the core Java SE API.
>    java.se.ee - Defines the full API of the Java SE Platform
> 
> Now that the java.se.ee module has been removed, the description of
> the java.se module summary should be changed to reflect the fact that
> it is the embodiment of the SE API.  Our module summaries will be
> as follows:
> 
>    java.base - Defines the foundational APIs of the Java SE Platform [no change]
>    java.se - Defines the API of the Java SE Platform
> 
> This is the diff:
> 
> diff -r 331888ea4a78 src/java.se/share/classes/module-info.java
> --- a/src/java.se/share/classes/module-info.java        Tue Jul 31 14:04:29 2018 -0700
> +++ b/src/java.se/share/classes/module-info.java        Mon Aug 06 
> 14:53:37 2018 -0700
> @@ -24,7 +24,7 @@
>  */
> 
> /**
> - * Defines the core Java SE API.
> + * Defines the API of the Java SE Platform.
>  * <P>
>  *
>  * <dl>
> 
> Thanks,
> iris

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From daniel.daugherty at oracle.com  Tue Aug  7 12:22:35 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 7 Aug 2018 08:22:35 -0400
Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690
In-Reply-To: <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com>
References: <b9f12b15-49e3-a61a-975c-f537f72f8ada@oracle.com>
 <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com>
Message-ID: <903c8fbc-9a0b-f9e3-1f91-b3448e552b92@oracle.com>

On 8/7/18 2:29 AM, Alan Bateman wrote:
> On 06/08/2018 17:49, Daniel D. Daugherty wrote:
>> :
>>
>> +java/net/Socket/LingerTest.java 8208690 generic-all
>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all
>> +
>> ?############################################################################ 
>>
> Can these tests be changed to /othervm instead of excluding them?
>
> -Alan

Maybe... I don't know if that would keep the tests from failing
or not. With 100+ of these failures in Mach5, you can see why
I was getting tired of it.

This is only until Jon's fix for:

 ??? https://bugs.openjdk.java.net/browse/CODETOOLS-7902259

gets promoted and we switch JDK12 to use it. I have a sub-task to
re-enable the tests when that happens.

Dan


From sean.mullan at oracle.com  Tue Aug  7 13:09:06 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 7 Aug 2018 09:09:06 -0400
Subject: [11] RFR: 8208691: Tighten up jdk.includeInExceptions security
 property
In-Reply-To: <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com>
References: <cc3d2e44-1d83-f4de-096a-6fb5e27e52d1@oracle.com>
 <0485c5c3-b3b3-34ca-e276-27f2ca6135b1@oracle.com>
Message-ID: <8bcc18af-8ef5-b354-3ecf-274ff669ac2f@oracle.com>

On 8/7/18 3:09 AM, Alan Bateman wrote:
> On 06/08/2018 20:23, Sean Mullan wrote:
>> After further evaluation of the new jdk.includeInExceptions security 
>> property originally introduced in JDK-8204233 [1] and further 
>> generalized in JDK-8207846 [2], I felt that a stronger warning should 
>> be added to the description of the property alerting the user to the 
>> potential risks of setting the property. I also added a test to ensure 
>> that the property was not accidentally turned on by default (mainly to 
>> catch accidental pushes where the property was left on as part of 
>> testing, etc).
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/
> I think it would simpler and read a bit better to just say "Use caution 
> before ...", meaning drop "NOTE" and "extra". The rest of the text is 
> okay. The additional test looks okay too.

I'll remove "extra" but I'd prefer to keep "NOTE" to draw attention to it.

--Sean

From roger.riggs at oracle.com  Tue Aug  7 13:57:42 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 7 Aug 2018 09:57:42 -0400
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <55f690c9-f21b-ee9d-aa30-f838b2da7257@gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <CAE+3fjZ09G4307tT70cOHada9iWED5UwCLJ36Fr8rfuxR9MNcw@mail.gmail.com>
 <55f690c9-f21b-ee9d-aa30-f838b2da7257@gmail.com>
Message-ID: <6d3d7ddb-7526-e3cf-b419-2ccc705b2936@oracle.com>

Hi,

As an API addition, it will need a CSR as well and it should have a 
couple of
reviewers that are fully aware of Streams design.

Regards, Roger


On 8/7/18 4:08 AM, Peter Levart wrote:
> Hi Tagir,
>
> Unless you have already got a sponsor (can't remember if somebody 
> already offered you a sponsorship), I can volunteer.
>
> Regarding the code, I only have one comment about the naming of the 
> last parameter: "finisher". To avoid confusion, it would be good to 
> name it differently from the Collector's functions. "finisher" and 
> "combiner" are already taken by Collector API. You describe the 
> parameter in javadoc as "the function which merges two results into 
> the single one". So what about "merger" or "result[s]Merger" ?
>
> ...and one comment about handling of IDENTITY_FINISH: You correctly 
> remove IDENTITY_FINISH from the resulting collector's characteristics, 
> but you don't honor the IDENTITY_FINISH characteristics of the two 
> parameter collectors. It should work nevertheless, but suppose some 
> "sloppy programmed" collector doesn't bother to return the identity 
> function when it announces that it has IDENTITY_FINISH characteristic...
>
> Regards, Peter
>
>
> On 08/07/2018 07:52 AM, Tagir Valeev wrote:
>> Ping! Could you please review and sponsor this changeset?
>> I updated version tag from since 11 to since 12:
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r2/
>>
>> Thanks in advance!
>>
>> With best regards,
>> Tagir Valeev.
>>
>> On Thu, Jun 21, 2018 at 11:33 AM Tagir Valeev <amaembo at gmail.com> wrote:
>>
>>> Please review and sponsor:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8205461
>>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>>>
>>> See also previous discussion thread at [1]. It seems that we did not 
>>> reach
>>> the final conclusion about the collector name, so in this review 
>>> it's still
>>> named as "pairing" (proposed by me). Other name proposals:
>>>
>>> bisecting - by Paul Sandoz (sounds like input is split by two parts 
>>> like
>>> in partitioningBy, which is not the case)
>>> tee or teeing - by Brian Goetz (IIUC from the T shape, it's 
>>> assymmetrical
>>> operation, while our collector is symmetrical)
>>> duplex(ing) - by Jacob Glickman (well, probably ok?)
>>> bifurcate - by James Laskey (or bifurcating?)
>>> replicator - by James Laskey (as in DNA)
>>> replicating - by Peter Levart
>>> fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked
>>> Wikipedia [2], does not look like suitable)
>>> distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac;
>>> but common meaning of "distributing" is different)
>>> tapping - by Kirk Pepperdine (I have no associations; Google images 
>>> shows
>>> some acupuncture procedures)
>>> split - by Kirk Pepperdine (may be confused with Spliterator)
>>> unzipping - by John Rose
>>> biMapping - by Zheka Kozlov (but he also suggests to change signature
>>> which is unnecessary)
>>> toBoth - by Peter Levart (but usually toXyz shows target container like
>>> toArray/toList/toSet, but there's not "Both" container)
>>> collectionToBothAndThen - by Zheka Kozlov (but too long)
>>> collectingToBoth - by Zheka Kozlov
>>> collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a 
>>> little
>>> bit repititive?)
>>> biCollecting - by Zheka Kozlov
>>> expanding - by Paul Sandoz (doesn't sound very descriptive to me)
>>> forking - by Victor Williams Stafusa da Silva (could be thought that
>>> something is parallelized as forking is usually something connected to
>>> parallel computations)
>>>
>>> I think that it's better to concentrate not on the "splitting" part 
>>> (each
>>> element is passed to two collectors), but on the "joining" part 
>>> (results of
>>> two collectors are combined together). So my preference now is 
>>> "merging" or
>>> "combining". If limiting the selection to the suggested options I'd 
>>> prefer
>>> "duplexing" or "bifurcating" or to stay with my original version 
>>> "pairing".
>>> Of course original Stream API author voices have more weight here, 
>>> so if
>>> you insist on particular version, I will follow.
>>>
>>> By the way looking into CollectorsTest.java I found some minor 
>>> things to
>>> cleanup:
>>> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced
>>> with simple `.map(mapper)` and `.flatMap(mapper)` respectively
>>> 2. In many methods redundant `throws ReflectiveOperationException` is
>>> declared while exception is never thrown
>>> 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks 
>>> useless as
>>> `map` is already of `Map<Boolean, D>` type, so this check is always 
>>> false
>>> (we would never enter this method if it's true). Similarly `if
>>> (!List.class.isAssignableFrom(value.getClass()))`
>>> 4. Deprecated `clazz.newInstance()` is used
>>> 5. Test named `testGroupubgByWithReducing` should be renamed to
>>> `testGroupingByWithReducing`
>>>
>>> Should I fix some or all of these issues? As separate changeset or 
>>> within
>>> this one?
>>>
>>> With best regards,
>>> Tagir Valeev.
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html 
>>>
>>> [2] https://en.wikipedia.org/wiki/Fan-out
>>>
>


From lenborje at gmail.com  Tue Aug  7 14:40:07 2018
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Tue, 7 Aug 2018 16:40:07 +0200
Subject: Draft JEP proposal: JDK-8200758: Packaging Tool
Message-ID: <9CF6C32F-403B-4128-B143-5BA926BA39AF@gmail.com>

I'm concerned about the possible loss of the packager service, i.e. the UserJvmOptionsService class and associated underlying machinery in the jpackager.

Background:

I'm developing and maintaining an internal GUI tool for log analysis.

It reads, parses and aggregates data from many different kinds of logs from our production systems. The amount of memory needed to process all the data can vary quite a lot from run to run, so I've found it very convenient to utilise the UserJvmOptionsService to enable my users to set and manage the JVM settings of the JVM-bundled application created by javapackager.

As far as I know, the javapackager, and the packager services, were omitted from JDK 11. While I can still use the javapackager of JDK 10 to package a JDK 11 application, I don't see how I could use the packager services, since they are not present. neither in JDK 11 nor in openjfx 11.

I would like to suggest the UserJvmOptionsService, or equivalent, be retained in the successor tool, jpackager.

Best regards,

/Lennart B?rjeson

From matthias.baesken at sap.com  Tue Aug  7 15:00:41 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 7 Aug 2018 15:00:41 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <252b3b00f4e94b8796256675ce2571b1@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
Message-ID: <9bb8b30850aa48e493a15d48cfd79efa@sap.com>

Ping ....  ??  , any reviews / comments ?

Thanks , Matthias

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Dienstag, 31. Juli 2018 12:28
> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; Alan Bateman
> <Alan.Bateman at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> Hello ,
> looks like  the  generalization of  the `includeInExceptions` security   property
> is now in jdk/jdk  after
> 
> "8207846: Generalize the jdk.net.includeInExceptions security property"
> 
> was added, great news  and thanks to Chris for driving this !
> 
> I use this security property now as well , and updated the  change :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
> 
> I updated the CSR as well :
> 
> https://bugs.openjdk.java.net/browse/JDK-8207768
> 
> 
> Best regards, Matthias
> 
> 
> 
> > -----Original Message-----
> > From: Chris Hegarty <chris.hegarty at oracle.com>
> > Sent: Donnerstag, 19. Juli 2018 14:54
> > To: Alan Bateman <Alan.Bateman at oracle.com>; Baesken, Matthias
> > <matthias.baesken at sap.com>
> > Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>
> > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> > parsing of jar archives
> >
> >
> > > On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com>
> > wrote:
> > >
> > > On 19/07/2018 09:07, Baesken, Matthias wrote:
> > >> Hello, in the meantime I  prepared a CSR :
> > >>
> > >> https://bugs.openjdk.java.net/browse/JDK-8207768
> > >>
> > >>
> > >>> jdk.includeInExceptions expands the scope. That might be okay but we
> > >>> will need to re-visit jdk.net.includeInExceptions and also move the
> > >>> support to somewhere in jdk.internal so that it can be used by other
> > >>> code in java.base.
> > >> Is there some support code for  " jdk.net.includeInExceptions "    or do
> > you just  mean  the name of the property ?
> > >>
> > > Chris is right that it's a bit premature to submit a CSR while the question
> on
> > whether to rename the existing security property is on the table. I have no
> > objection to doing that.
> >
> > I filed the following issue to generalize the `includeInExceptions` security
> >  property:
> >   https://bugs.openjdk.java.net/browse/JDK-8207846
> >
> > I would like to resolve 8207846 first, then 8205525 can propose to add the
> > new argument value, `jarPath`.
> >
> > -Chris.

From claes.redestad at oracle.com  Tue Aug  7 16:16:27 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 7 Aug 2018 18:16:27 +0200
Subject: RFR: 8209003: Consolidate use of empty collections in java.lang.module
Message-ID: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>

Hi,

feel free to review this cleanup to consolidate some uses of 
Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as 
appropriate. This aligns better with code already generated by jlink, so 
avoids observing a mix of many implementation classes in some places..

Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8209003

Due the specified need to throw IAE rather than NPE in certain cases, 
code in some performance-insensitive API methods in 
ModuleDescriptor.Builder now does an extra copy up front 
(List/Set/Map.copyOf will throw NPE on any null element or key). I'd 
rather keep the code simple than add extra handling to squeeze out the 
last bit of performance here (maybe I'm getting old...)

Thanks!

/Claes


From brian.goetz at oracle.com  Tue Aug  7 16:22:04 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 7 Aug 2018 12:22:04 -0400
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
Message-ID: <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>


On 6/21/2018 12:33 AM, Tagir Valeev wrote:
> Please review and sponsor:
>
> https://bugs.openjdk.java.net/browse/JDK-8205461
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>
> See also previous discussion thread at [1]. It seems that we did not reach
> the final conclusion about the collector name, so in this review it's still
> named as "pairing" (proposed by me). Other name proposals:

None of the names so far are great.? The essential challenge in naming 
here is that this Collector does two (or maybe three) things: duplicate 
the stream into two identical streams ("tee"), sends each element to the 
two collectors ("collecting"), and then combines the results 
("finishing").? So all the one-word names (pairing, teeing, unzipping, 
biMapping) only emphasize one half of the operation, and names that 
capture the full workflow accurately (teeingAndCollectingAndThen) are 
unwieldy.

Of the three phases, teeing is the most important and least obvious, so 
I think something that includes that in the name is going to be 
helpful.? Perhaps "teeingAndThen" is more evocative and not totally 
unwieldy.

Names along the lines of "merging" may incorrectly give the idea that 
the merge is happening elementwise, rather than duplicating the streams, 
collecting, and merging the results.

> By the way looking into CollectorsTest.java I found some minor things to
> cleanup:
> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
> simple `.map(mapper)` and `.flatMap(mapper)` respectively
Does IntelliJ have an inspection for eliminating such locutions?
> 2. In many methods redundant `throws ReflectiveOperationException` is
> declared while exception is never thrown
For test code where a significant fraction of test cases are going to 
throw something, we often do this, since its easier to just uniformly 
tag such methods rather than thinking about which test methods actually 
throw the exception and which don't.? So I think this is harmless 
(though cleaning it up is harmless too.)


You may want to optimize the EnumSet mechanics for the case where 
neither collector has interesting characteristics.



From mandy.chung at oracle.com  Tue Aug  7 17:38:33 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Aug 2018 10:38:33 -0700
Subject: RFR (XXS) 8201394: Update java.se module summary to reflect
 removal of java.se.ee module
In-Reply-To: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
References: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
Message-ID: <876c4390-0ea4-4e53-7f06-7de55614d015@oracle.com>



On 8/6/18 8:21 PM, Iris Clark wrote:
> 
> diff -r 331888ea4a78 src/java.se/share/classes/module-info.java
> --- a/src/java.se/share/classes/module-info.java        Tue Jul 31 14:04:29 2018 -0700
> +++ b/src/java.se/share/classes/module-info.java        Mon Aug 06
> 14:53:37 2018 -0700
> @@ -24,7 +24,7 @@
>    */
> 
>   /**
> - * Defines the core Java SE API.
> + * Defines the API of the Java SE Platform.
>    * <P>
>    *
>    * <dl>


Looks good.

Mandy

From Alan.Bateman at oracle.com  Tue Aug  7 18:25:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 Aug 2018 19:25:45 +0100
Subject: RFR: 8209003: Consolidate use of empty collections in
 java.lang.module
In-Reply-To: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>
References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>
Message-ID: <a55ecc62-f225-fec0-0070-24c4d17ce5ea@oracle.com>

On 07/08/2018 17:16, Claes Redestad wrote:
> Hi,
>
> feel free to review this cleanup to consolidate some uses of 
> Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as 
> appropriate. This aligns better with code already generated by jlink, 
> so avoids observing a mix of many implementation classes in some places..
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209003
>
> Due the specified need to throw IAE rather than NPE in certain cases, 
> code in some performance-insensitive API methods in 
> ModuleDescriptor.Builder now does an extra copy up front 
> (List/Set/Map.copyOf will throw NPE on any null element or key). I'd 
> rather keep the code simple than add extra handling to squeeze out the 
> last bit of performance here (maybe I'm getting old...)
This looks okay, I don't see anywhere where the behavior changes.

-Alan

From mandy.chung at oracle.com  Tue Aug  7 19:05:48 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Aug 2018 12:05:48 -0700
Subject: RFR: 8209003: Consolidate use of empty collections in
 java.lang.module
In-Reply-To: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>
References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>
Message-ID: <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com>

This cleanup looks fine.

Mandy

On 8/7/18 9:16 AM, Claes Redestad wrote:
> Hi,
> 
> feel free to review this cleanup to consolidate some uses of 
> Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as 
> appropriate. This aligns better with code already generated by jlink, so 
> avoids observing a mix of many implementation classes in some places..
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8209003/jdk.00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209003
> 
> Due the specified need to throw IAE rather than NPE in certain cases, 
> code in some performance-insensitive API methods in 
> ModuleDescriptor.Builder now does an extra copy up front 
> (List/Set/Map.copyOf will throw NPE on any null element or key). I'd 
> rather keep the code simple than add extra handling to squeeze out the 
> last bit of performance here (maybe I'm getting old...)
> 
> Thanks!
> 
> /Claes
> 

From Roger.Riggs at Oracle.com  Tue Aug  7 19:11:57 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 7 Aug 2018 15:11:57 -0400
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <8F1354FE-BD3F-47CA-84CB-73B996B36FAD@oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
 <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
 <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>
 <a8609400-6797-dd5c-ca1f-e045998f2d59@Oracle.com>
 <8F1354FE-BD3F-47CA-84CB-73B996B36FAD@oracle.com>
Message-ID: <902483f5-8e9c-f38a-fada-da8a3c96ba9e@Oracle.com>

Hi Chris,

Looks ok.

For future tests, I think I would put the contents of the initContext() 
methods inline in the test method so the setup and the testing of the 
conditions were in the same method, making it easier to read.

Thanks, Roger


On 8/6/2018 11:53 PM, Chris Yin wrote:
> Hi, Roger
>
> Thanks a lot for your review and comments, inline and updated webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208279/webrev.03/
>
>> On 6 Aug 2018, at 10:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi Chris,
>>
>> EnvTestBase.java:  The class and each of the methods should have javadoc with a descriptive comment
>> to make the test construction easier to understand for future maintenance especially since
>> they are shared/overridden and used by many of the test cases.
>> For example, verifyEnvProperty should say what is true about a valid property.
>> With many layers of inherited test methods it needs easier to understand what comes from where.
>> Build good habits with writing complete sentences with capitalization and punctuation in comments.
> Sure, I added javadoc to EnvTestBase class and shared/override methods (except getter/setter), will also complement javadoc to test base class in other review thread, thanks
>
>> initContext() belongs in DNSTestBase along with context() and setContext() to avoid splitting that
>> function across multiple classes.
>> Or remove initContext() since it is overridden in several tests (without calling super) and
>> just call setContext() with new InitialDirContext(env()) consistently in each test.
> Yep, I hesitated at first whether put initContext() to DNSTestBase, after look through many dns test cases, I found there are a lot of tests may need to override it and some case to use parameterized method will be easier (such as initContext(String, String) used in Factory Tests), so I decided to leave it to each sub test base or tests to customize. Anyway we could refactor it later if we found that way better.
> For now I removed initContext() from EnvTestBase as you suggested in 2nd and used private initContext() for complex initialization or just call setContext with new InitialDirContext(env()) for simple one, thanks
>
>> ProviderUrlGen.java should not mention SWAN by name as it is an internal resource
>> (and that's not the current name).
> Sure, removed that name
>
>> RemoveInherited.java: for strings that need to be consistent across the test, they should be defined as
>> final statics so there is only one declaration.
> Fixed as your suggested
>
> Thanks & Regards,
> Chris
>
>> Thanks, Roger
>>
>> On 8/6/2018 3:09 AM, Chris Yin wrote:
>>> Thank you, Vyom
>>>
>>> Regards,
>>> Chris
>>>
>>>> On 6 Aug 2018, at 2:02 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>
>>>> Hi Chris,
>>>>
>>>> Latest webrev looks good to me.
>>>>
>>>> Thanks,
>>>>
>>>> Vyom
>>>>
>>>>
>>>> On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
>>>>> Hi, Vyom
>>>>>
>>>>> Thank a lot for your review and comments, inline and update new webrev as below
>>>>>
>>>>> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/
>>>>>
>>>>>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Overall looks good to me, couple of minor comment.
>>>>>>
>>>>>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
>>>>> Fixed, thanks
>>>>>
>>>>>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
>>>>> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>>>>>
>>>>> Thanks,
>>>>> Chris
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>>>>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Chris
>>>>>>>
>>>>>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Chris


From roger.riggs at oracle.com  Tue Aug  7 20:37:48 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 7 Aug 2018 16:37:48 -0400
Subject: 8143850: retrofit ArrayDeque to implement List
In-Reply-To: <f58d02a0-550e-0f3b-fe0c-e435bb6aa40b@gmail.com>
References: <CY4PR1601MB1125DCD8F9281E6BDB3CFDCAA5490@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe08vZcjtXkxmWkhBkH8FJc81kBX-hs-t1rC_yHbDivDHkg@mail.gmail.com>
 <CY4PR1601MB1125C26A587B2B4772C7B29AA54E0@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <CA+kOe0-jfxRvT1xULDKNDAB8FUjMXybaBL_K1AUCdvsc622M=w@mail.gmail.com>
 <DM5PR1601MB1132AAE82717D7EA1757879CA5450@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <CA+kOe08BUp=f=K1koQUNd1UbK9Jjigj+aDKF_HFYHhV3+exGGw@mail.gmail.com>
 <b1d84218-e591-ba78-f602-7a6f472d58ff@oracle.com>
 <CY4PR1601MB1125ECAD1EA5D442339DB5B2A5280@CY4PR1601MB1125.namprd16.prod.outlook.com>
 <6f2ec600-288f-8cea-9ba9-4748c3e8ad5d@oracle.com>
 <DM5PR1601MB113260B3D990190B725D1D54A52E0@DM5PR1601MB1132.namprd16.prod.outlook.com>
 <e126a760-de69-e91f-aa21-d44c30bc81e0@reini.net>
 <7e10860f-2619-df70-4fdb-7dbc60a429ee@reini.net>
 <5fd3e7c3-a0a2-fbe5-79bc-f9e5676466b4@oracle.com>
 <f58d02a0-550e-0f3b-fe0c-e435bb6aa40b@gmail.com>
Message-ID: <92b5ec05-bc25-68f9-dcae-524283d2ae2a@oracle.com>

Hi,

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.

$.02, Roger

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 
>> 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
>>>
>


From claes.redestad at oracle.com  Tue Aug  7 21:16:54 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 7 Aug 2018 23:16:54 +0200
Subject: RFR: 8209003: Consolidate use of empty collections in
 java.lang.module
In-Reply-To: <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com>
References: <672abe23-313b-4ce4-1bf6-d556ef14e9cc@oracle.com>
 <8eb978c2-6388-5a39-a321-c447daea6249@oracle.com>
Message-ID: <09ca9dcc-95ae-73b5-c625-5956b934a9ed@oracle.com>

Alan, Mandy,

thanks for reviewing. Pushed.

/Claes


On 2018-08-07 21:05, mandy chung wrote:
> This cleanup looks fine.
>
> Mandy


From igor.ignatyev at oracle.com  Tue Aug  7 21:19:03 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 7 Aug 2018 14:19:03 -0700
Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files
Message-ID: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html
> 18 lines changed: 3 ins; 5 del; 10 mod; 

Hi all,

could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part.

NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly. 

JBS: https://bugs.openjdk.java.net/browse/JDK-8205687
webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html

Thanks,
-- Igor

From brian.burkhalter at oracle.com  Tue Aug  7 22:41:20 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 7 Aug 2018 15:41:20 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
Message-ID: <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>

Hi Matthias,

Yes, that was intentional. From the documentation it looks as if the Linux / Solaris *64 functions in question are now legacy so I changed them for hopefully better consistency. I did not see any problems in building or testing with these changes. If someone knows these changes to be incorrect then I would appreciate being so informed.

Does this latest (.03) patch check out on AIX?

Thanks,

Brian

On Aug 7, 2018, at 3:12 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:

> small remark from my side ,  looks like you changed in
>  
> src/java.base/unix/native/libjava/TimeZone_md.c
>  
> src/java.base/unix/native/libjava/childproc.c
>  
> and
>  
> src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
>  
> at some places  dirent64  /  readdir64   to   dirent  /  readdir
> in the linux/solaris  coding.
>  
> for example
>  
> TimeZone_md.c
>  
> 122 static char *
> 123 findZoneinfoFile(char *buf, size_t size, const char *dir)
> 124 {
> 125     DIR *dirp = NULL;
> 126     struct stat statbuf;
> 127     struct dirent *dp = NULL;.
>  
>  
> Was it intended  to  change for linux/solaris ?


From iris.clark at oracle.com  Wed Aug  8 00:43:21 2018
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 7 Aug 2018 17:43:21 -0700 (PDT)
Subject: RFR (XXS) 8201394: Update java.se module summary to reflect
 removal of java.se.ee module
In-Reply-To: <876c4390-0ea4-4e53-7f06-7de55614d015@oracle.com>
References: <40d8e8e4-d29f-4e65-bf00-39bb9d89810b@default>
 <876c4390-0ea4-4e53-7f06-7de55614d015@oracle.com>
Message-ID: <83a18b3d-3784-475d-904c-407a3514edf9@default>

Pushed.

Thank your Lance, Alan, and Mandy for the super-fast reviews!

iris

-----Original Message-----
From: mandy chung 
Sent: Tuesday, August 7, 2018 10:39 AM
To: Iris Clark <iris.clark at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR (XXS) 8201394: Update java.se module summary to reflect removal of java.se.ee module



On 8/6/18 8:21 PM, Iris Clark wrote:
> 
> diff -r 331888ea4a78 src/java.se/share/classes/module-info.java
> --- a/src/java.se/share/classes/module-info.java        Tue Jul 31 14:04:29 2018 -0700
> +++ b/src/java.se/share/classes/module-info.java        Mon Aug 06
> 14:53:37 2018 -0700
> @@ -24,7 +24,7 @@
>    */
> 
>   /**
> - * Defines the core Java SE API.
> + * Defines the API of the Java SE Platform.
>    * <P>
>    *
>    * <dl>


Looks good.

Mandy

From xu.y.yin at oracle.com  Wed Aug  8 01:46:50 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Wed, 8 Aug 2018 09:46:50 +0800
Subject: [12] RFR 8208279: Add 8 JNDI tests to com/sun/jndi/dns/EnvTests/
In-Reply-To: <902483f5-8e9c-f38a-fada-da8a3c96ba9e@Oracle.com>
References: <0EFABB87-51B9-4454-85DF-33C49C7BF805@oracle.com>
 <2ED52B01-8332-4BC4-966C-0C3DF85897B2@oracle.com>
 <24131d57-e80e-e484-7bf2-15451108317a@oracle.com>
 <2CE9CCEB-9E19-460C-96A0-6320A06F63AA@oracle.com>
 <8404a257-2014-c4e8-7edd-ef7aa32f4439@oracle.com>
 <7FB4084A-FCDE-4A82-8380-7BA0FAA3BB34@oracle.com>
 <a8609400-6797-dd5c-ca1f-e045998f2d59@Oracle.com>
 <8F1354FE-BD3F-47CA-84CB-73B996B36FAD@oracle.com>
 <902483f5-8e9c-f38a-fada-da8a3c96ba9e@Oracle.com>
Message-ID: <FD2381B0-C390-4B67-B9E0-17460B071D9A@oracle.com>

Thank you Roger, sure, I will expand initContext() inline in the test method for future tests

Regards,
Chris

> On 8 Aug 2018, at 3:11 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Chris,
> 
> Looks ok.
> 
> For future tests, I think I would put the contents of the initContext() methods inline in the test method so the setup and the testing of the conditions were in the same method, making it easier to read.
> 
> Thanks, Roger
> 
> 
> On 8/6/2018 11:53 PM, Chris Yin wrote:
>> Hi, Roger
>> 
>> Thanks a lot for your review and comments, inline and updated webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208279/webrev.03/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.03/>
>> 
>>> On 6 Aug 2018, at 10:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> <mailto:Roger.Riggs at Oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> EnvTestBase.java:  The class and each of the methods should have javadoc with a descriptive comment
>>> to make the test construction easier to understand for future maintenance especially since
>>> they are shared/overridden and used by many of the test cases.
>>> For example, verifyEnvProperty should say what is true about a valid property.
>>> With many layers of inherited test methods it needs easier to understand what comes from where.
>>> Build good habits with writing complete sentences with capitalization and punctuation in comments.
>> Sure, I added javadoc to EnvTestBase class and shared/override methods (except getter/setter), will also complement javadoc to test base class in other review thread, thanks
>> 
>>> initContext() belongs in DNSTestBase along with context() and setContext() to avoid splitting that
>>> function across multiple classes.
>>> Or remove initContext() since it is overridden in several tests (without calling super) and
>>> just call setContext() with new InitialDirContext(env()) consistently in each test.
>> Yep, I hesitated at first whether put initContext() to DNSTestBase, after look through many dns test cases, I found there are a lot of tests may need to override it and some case to use parameterized method will be easier (such as initContext(String, String) used in Factory Tests), so I decided to leave it to each sub test base or tests to customize. Anyway we could refactor it later if we found that way better.
>> For now I removed initContext() from EnvTestBase as you suggested in 2nd and used private initContext() for complex initialization or just call setContext with new InitialDirContext(env()) for simple one, thanks
>> 
>>> ProviderUrlGen.java should not mention SWAN by name as it is an internal resource
>>> (and that's not the current name).
>> Sure, removed that name
>> 
>>> RemoveInherited.java: for strings that need to be consistent across the test, they should be defined as
>>> final statics so there is only one declaration.
>> Fixed as your suggested
>> 
>> Thanks & Regards,
>> Chris
>> 
>>> Thanks, Roger
>>> 
>>> On 8/6/2018 3:09 AM, Chris Yin wrote:
>>>> Thank you, Vyom
>>>> 
>>>> Regards,
>>>> Chris
>>>> 
>>>>> On 6 Aug 2018, at 2:02 PM, vyom tewari <vyom.tewari at oracle.com> <mailto:vyom.tewari at oracle.com> wrote:
>>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> Latest webrev looks good to me.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Vyom
>>>>> 
>>>>> 
>>>>> On Friday 03 August 2018 02:46 PM, Chris Yin wrote:
>>>>>> Hi, Vyom
>>>>>> 
>>>>>> Thank a lot for your review and comments, inline and update new webrev as below
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~xyin/8208279/webrev.02/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.02/>
>>>>>> 
>>>>>>> On 3 Aug 2018, at 3:45 PM, vyom tewari <vyom.tewari at oracle.com> <mailto:vyom.tewari at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> Overall looks good to me, couple of minor comment.
>>>>>>> 
>>>>>>> 1-> ProviderUrlGen.java, Line:100 Exception e can be replaced with specific  exceptions.
>>>>>> Fixed, thanks
>>>>>> 
>>>>>>> 2-> In couple of  places we are calling "removeFromEnvironment" on context and spec says it will return "null" if the env is not set. I  see that we are setting the required env in "initContext"  so it will never be "null" in our tests, but i  suggest you to put just one liner comment that "val" can not be null. This is just to improve code readability, please feel free to ignore, if you think it is not worth enough.
>>>>>> Sure, added one line comment before each ?removeFromEnvironment? call as you suggested
>>>>>> 
>>>>>> Thanks,
>>>>>> Chris
>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Vyom
>>>>>>> 
>>>>>>> 
>>>>>>> On Monday 30 July 2018 08:41 AM, Chris Yin wrote:
>>>>>>>> Please find the new webrev as below, it addressed some similar issues which mentioned in review comments from another thread RFR 8200151, thanks
>>>>>>>> 
>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.01/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/> <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/> <http://cr.openjdk.java.net/~xyin/8208279/webrev.01/>
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Chris
>>>>>>>> 
>>>>>>>>> On 26 Jul 2018, at 3:37 PM, Chris Yin <xu.y.yin at oracle.com> <mailto:xu.y.yin at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Please review the changes to add another 8 JNDI tests to com/sun/jndi/dns/EnvTests/ in OpenJDK, thanks
>>>>>>>>> 
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208279 <https://bugs.openjdk.java.net/browse/JDK-8208279> <https://bugs.openjdk.java.net/browse/JDK-8208279> <https://bugs.openjdk.java.net/browse/JDK-8208279>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208279/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/> <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/> <http://cr.openjdk.java.net/~xyin/8208279/webrev.00/>
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Chris
> 


From xu.y.yin at oracle.com  Wed Aug  8 03:41:22 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Wed, 8 Aug 2018 11:41:22 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
Message-ID: <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>

Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208483/webrev.04/

Regards,
Chris

> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Hi, Vyom
> 
> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
> 
> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
> 
> Regards,
> Chris
> 
>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>> 
>> Hi Chris,
>> 
>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>> 
>> .Thanks,
>> 
>> Vyom
>> 
>> 
>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>> Hi, Vyom
>>> 
>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>> 
>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>> 
>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>> 
>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>> 
>>> * @return The object created; null if an object cannot be created.
>>> * @exception Exception If this object factory encountered an exception
>>> * while attempting to create an object, and no other object factories are
>>> * to be tried.
>>> 
>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>> Same as above
>>> 
>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>> 
>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>> 
>>> Thanks & Regards,
>>> Chris
>>> 
>>>> Thanks,
>>>> 
>>>> Vyom
>>>> 
>>>> 
>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>> 
>>>>> Regards,
>>>>> Chris
>> 
> 


From david.holmes at oracle.com  Wed Aug  8 04:00:26 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Aug 2018 14:00:26 +1000
Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files
In-Reply-To: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com>
References: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com>
Message-ID: <d6e53c9c-1814-ff6a-c8a0-b6f4fba86721@oracle.com>

Hi Igor,

This all seems okay. However we probably need to check that the people 
operating their own build/test farms are okay with this change.

Don't forget to update copyright years.

Minor comment below ...

On 8/08/2018 7:19 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html
>> 18 lines changed: 3 ins; 5 del; 10 mod;
> 
> Hi all,
> 
> could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part.

Can you add a comment in GathererFactory to explain that as well please.

Thanks,
David

> 
> NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8205687
> webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html
> 
> Thanks,
> -- Igor
> 

From xu.y.yin at oracle.com  Wed Aug  8 06:51:01 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Wed, 8 Aug 2018 14:51:01 +0800
Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/
In-Reply-To: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com>
References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com>
Message-ID: <DC4F9209-8A0A-4CBE-89B9-97603DD5E408@oracle.com>

Minor revision to address javadoc, initContext() expansion, vararg etc. webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208542/webrev.01/ 

Regards,
Chris

> On 31 Jul 2018, at 2:39 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Please review the changes to add 4 JNDI tests to com/sun/jndi/dns/ListTests/ in OpenJDK, thanks
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8208542
> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/
> 
> Regards,
> Chris


From vyom.tewari at oracle.com  Wed Aug  8 07:12:45 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Wed, 8 Aug 2018 12:42:45 +0530
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
Message-ID: <64015711-af69-fa6b-fd76-c96aa533640e@oracle.com>

Hi Chris,

Latest code webrev(.03) looks good to me, expending initContext() makes 
tests more readable :) .

Thanks,

Vyom


On Wednesday 08 August 2018 09:11 AM, Chris Yin wrote:
> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>
> Regards,
> Chris
>
>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>
>> Hi, Vyom
>>
>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>
>> Regards,
>> Chris
>>
>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>
>>> Hi Chris,
>>>
>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>
>>> .Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>> Hi, Vyom
>>>>
>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>
>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>
>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>
>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>
>>>> * @return The object created; null if an object cannot be created.
>>>> * @exception Exception If this object factory encountered an exception
>>>> * while attempting to create an object, and no other object factories are
>>>> * to be tried.
>>>>
>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>> Same as above
>>>>
>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>
>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>
>>>> Thanks & Regards,
>>>> Chris
>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>
>>>>>> Regards,
>>>>>> Chris


From xu.y.yin at oracle.com  Wed Aug  8 07:26:04 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Wed, 8 Aug 2018 15:26:04 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <64015711-af69-fa6b-fd76-c96aa533640e@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
 <64015711-af69-fa6b-fd76-c96aa533640e@oracle.com>
Message-ID: <181A1770-7DDD-4352-AE7A-677E3189A1F1@oracle.com>

Thank you, Vyom

Regards,
Chris

> On 8 Aug 2018, at 3:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Latest code webrev(.03) looks good to me, expending initContext() makes tests more readable :) .
> 
> Thanks,
> 
> Vyom
> 
> 
> On Wednesday 08 August 2018 09:11 AM, Chris Yin wrote:
>> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>> 
>> Regards,
>> Chris
>> 
>>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Hi, Vyom
>>> 
>>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>> 
>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>> 
>>> Regards,
>>> Chris
>>> 
>>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>> 
>>>> .Thanks,
>>>> 
>>>> Vyom
>>>> 
>>>> 
>>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>>> Hi, Vyom
>>>>> 
>>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>> 
>>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>> 
>>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>> 
>>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>> 
>>>>> * @return The object created; null if an object cannot be created.
>>>>> * @exception Exception If this object factory encountered an exception
>>>>> * while attempting to create an object, and no other object factories are
>>>>> * to be tried.
>>>>> 
>>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>>> Same as above
>>>>> 
>>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>> 
>>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>> 
>>>>> Thanks & Regards,
>>>>> Chris
>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Vyom
>>>>>> 
>>>>>> 
>>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>> 
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Chris
> 


From roger.riggs at oracle.com  Wed Aug  8 13:52:15 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 8 Aug 2018 09:52:15 -0400
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
Message-ID: <b7f642a6-4b47-a3b1-e7bf-c797b4628293@oracle.com>

Hi Chris,

Each of these tests is going to spawn a new process (/othervm). That's a 
lot of overhead for a short test.

Can these be written as TestNG tests so they run quicker and more tests 
be in a single source file
and run in single VM?

@Override should be on its own line so the method signature is on a line 
by itself too.
Setup your IDE to use the formatting conventions and let it reformat.

LookupFactoryBase.java: 67 / 84? - Be consistent about the form of 
messages,
 ?I prefer the Expected xxx but found yyy form.?? (no need to say it 
failed, it threw an exception).

The imports should be before the comment with the jtreg test description.

Thanks, Roger

On 8/7/18 11:41 PM, Chris Yin wrote:
> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>
> Regards,
> Chris
>
>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>
>> Hi, Vyom
>>
>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>
>> Regards,
>> Chris
>>
>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>
>>> Hi Chris,
>>>
>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>
>>> .Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>> Hi, Vyom
>>>>
>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>
>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>
>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>
>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>
>>>> * @return The object created; null if an object cannot be created.
>>>> * @exception Exception If this object factory encountered an exception
>>>> * while attempting to create an object, and no other object factories are
>>>> * to be tried.
>>>>
>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>> Same as above
>>>>
>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>
>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>
>>>> Thanks & Regards,
>>>> Chris
>>>>
>>>>> Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>
>>>>>> Regards,
>>>>>> Chris


From sean.mullan at oracle.com  Wed Aug  8 15:00:38 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Aug 2018 11:00:38 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
Message-ID: <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>

Cross-posting to security-dev since this fix is security related and 
should also be reviewed there.

--Sean

On 8/7/18 11:00 AM, Baesken, Matthias wrote:
> Ping ....  ??  , any reviews / comments ?
> 
> Thanks , Matthias
> 
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Dienstag, 31. Juli 2018 12:28
>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; Alan Bateman
>> <Alan.Bateman at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>; Langer, Christoph
>> <christoph.langer at sap.com>
>> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>>
>> Hello ,
>> looks like  the  generalization of  the `includeInExceptions` security   property
>> is now in jdk/jdk  after
>>
>> "8207846: Generalize the jdk.net.includeInExceptions security property"
>>
>> was added, great news  and thanks to Chris for driving this !
>>
>> I use this security property now as well , and updated the  change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
>>
>> I updated the CSR as well :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8207768
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>> -----Original Message-----
>>> From: Chris Hegarty <chris.hegarty at oracle.com>
>>> Sent: Donnerstag, 19. Juli 2018 14:54
>>> To: Alan Bateman <Alan.Bateman at oracle.com>; Baesken, Matthias
>>> <matthias.baesken at sap.com>
>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
>>> <goetz.lindenmaier at sap.com>
>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>>> parsing of jar archives
>>>
>>>
>>>> On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>>
>>>> On 19/07/2018 09:07, Baesken, Matthias wrote:
>>>>> Hello, in the meantime I  prepared a CSR :
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768
>>>>>
>>>>>
>>>>>> jdk.includeInExceptions expands the scope. That might be okay but we
>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the
>>>>>> support to somewhere in jdk.internal so that it can be used by other
>>>>>> code in java.base.
>>>>> Is there some support code for  " jdk.net.includeInExceptions "    or do
>>> you just  mean  the name of the property ?
>>>>>
>>>> Chris is right that it's a bit premature to submit a CSR while the question
>> on
>>> whether to rename the existing security property is on the table. I have no
>>> objection to doing that.
>>>
>>> I filed the following issue to generalize the `includeInExceptions` security
>>>   property:
>>>    https://bugs.openjdk.java.net/browse/JDK-8207846
>>>
>>> I would like to resolve 8207846 first, then 8205525 can propose to add the
>>> new argument value, `jarPath`.
>>>
>>> -Chris.

From naoto.sato at oracle.com  Wed Aug  8 18:13:50 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 8 Aug 2018 11:13:50 -0700
Subject: <i18n dev> [12]RFR 8208656: Move
 java/util/Calendar/CalendarTestScripts tests into OpenJDK
In-Reply-To: <564a5be8-df5a-69a8-8fb4-9dc2f8015503@oracle.com>
References: <564a5be8-df5a-69a8-8fb4-9dc2f8015503@oracle.com>
Message-ID: <a91d5bee-51c8-cf0f-2d63-f8335402ac3a@oracle.com>

Looks good. Please add "noreg-self" label to the issue.

Naoto

On 8/7/18 12:31 AM, Ying Zhou wrote:
> Hello,
> 
> Please help review the patch to move some tests to OpenJDK. Thank you!
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8208656
> 
> Webrev: http://cr.openjdk.java.net/~dzhou/8208656/webrev.00/ 
> <http://cr.openjdk.java.net/%7Edzhou/8208656/webrev.00/>
> 
> Regards,
> 
> Daisy
> 

From Alan.Bateman at oracle.com  Wed Aug  8 18:29:46 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 Aug 2018 19:29:46 +0100
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
Message-ID: <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com>

On 07/08/2018 16:00, Baesken, Matthias wrote:
> Ping ....  ??  , any reviews / comments ?
Did we get to a conclusion on whether to have central infrastructure to 
read/parse the security property? As I recall, this one was originally 
proposed before the generalization of the networking solution. There are 
details related to trimming that would be better not to duplicate if 
possible.

Also, I think one of my comments on the original patch is that we should 
get the style and line lengths a bit more consistent with the existing 
code (the patch added excessively long lines for example).

-Alan.

From brent.christian at oracle.com  Wed Aug  8 18:57:22 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 8 Aug 2018 11:57:22 -0700
Subject: [12]RFR 8205399 : Set node color on pinned HashMap.TreeNode deletion
Message-ID: <3f43185c-13e2-4f65-1da0-a2c605571f58@oracle.com>

Hi,

Please review the following fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8205399
Webrev: http://cr.openjdk.java.net/~bchristi/8205399/webrev01/

The vmTestbase/vm/gc/containers/Combination05/TestDescription.java test, 
which does random adds and removes (via Iterator), has been failing 
intermittently with an AssertionError.

I tracked down a couple sequences of operations that trigger the 
assertion.  Sufficient HashMap collisions convert a bin to a tree, and 
then values are deleted using Iterator.remove() (pinned node deletion).

The condition that fails in HashMap.TreeNode.checkInvariants() is:

   if (t.red && tl != null && tl.red && tr != null && tr.red)

A red TreeNode should not have two red children.

Many thanks to Doug Lea for providing the fix for the HashMap red/black 
tree code.  The root node color needs to be set in this case.

Thanks,
-Brent

From martinrb at google.com  Wed Aug  8 20:23:29 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Aug 2018 13:23:29 -0700
Subject: [12]RFR 8205399 : Set node color on pinned HashMap.TreeNode
 deletion
In-Reply-To: <3f43185c-13e2-4f65-1da0-a2c605571f58@oracle.com>
References: <3f43185c-13e2-4f65-1da0-a2c605571f58@oracle.com>
Message-ID: <CA+kOe08qGzAnX014C75=Fyzk_Nbo1cV+pAZFcZajLcemD7inDA@mail.gmail.com>

Brent, thanks for writing a test.
I would probably not have bothered.  Or if I was ambitious, I might have
written a whitebox test against all the red-black tree implementations in
the core libs, verifying node color.

+        int hash;

final?

+    static class Key implements Comparable {

implements Comparable<Key> ?

+        @Override public int compareTo(Object k) {
+            return this.hash - ((Key)k).hash;
+        }

Buggy - use Integer.compare instead.
https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/lang/Integer.html#compare(int,int)

Approved.


On Wed, Aug 8, 2018 at 11:57 AM, Brent Christian <brent.christian at oracle.com
> wrote:

> Hi,
>
> Please review the following fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205399
> Webrev: http://cr.openjdk.java.net/~bchristi/8205399/webrev01/
>
> The vmTestbase/vm/gc/containers/Combination05/TestDescription.java test,
> which does random adds and removes (via Iterator), has been failing
> intermittently with an AssertionError.
>
> I tracked down a couple sequences of operations that trigger the
> assertion.  Sufficient HashMap collisions convert a bin to a tree, and then
> values are deleted using Iterator.remove() (pinned node deletion).
>
> The condition that fails in HashMap.TreeNode.checkInvariants() is:
>
>   if (t.red && tl != null && tl.red && tr != null && tr.red)
>
> A red TreeNode should not have two red children.
>
> Many thanks to Doug Lea for providing the fix for the HashMap red/black
> tree code.  The root node color needs to be set in this case.
>
> Thanks,
> -Brent
>

From brent.christian at oracle.com  Wed Aug  8 20:57:35 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 8 Aug 2018 13:57:35 -0700
Subject: [12]RFR 8205399 : Set node color on pinned HashMap.TreeNode
 deletion
In-Reply-To: <CA+kOe08qGzAnX014C75=Fyzk_Nbo1cV+pAZFcZajLcemD7inDA@mail.gmail.com>
References: <3f43185c-13e2-4f65-1da0-a2c605571f58@oracle.com>
 <CA+kOe08qGzAnX014C75=Fyzk_Nbo1cV+pAZFcZajLcemD7inDA@mail.gmail.com>
Message-ID: <92dcbca3-2dce-10f9-9499-656882099d52@oracle.com>

Thank you for the review, Martin.
Good suggestions, thanks.

-Brent

On 08/08/2018 01:23 PM, Martin Buchholz wrote:
> Brent, thanks for writing a test.
> I would probably not have bothered.  Or if I was ambitious, I might have
> written a whitebox test against all the red-black tree implementations
> in the core libs, verifying node color.
>
> +        int hash;
>
> final?
>
> +    static class Key implements Comparable {
>
> implements Comparable<Key> ?
>
> +        @Override public int compareTo(Object k) {
> +            return this.hash - ((Key)k).hash;
> +        }
>
> Buggy - use Integer.compare instead.
> https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/lang/Integer.html#compare(int,int)
>
> Approved.
>
>
> On Wed, Aug 8, 2018 at 11:57 AM, Brent Christian
> <brent.christian at oracle.com <mailto:brent.christian at oracle.com>> wrote:
>
>     Hi,
>
>     Please review the following fix.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8205399
>     <https://bugs.openjdk.java.net/browse/JDK-8205399>
>     Webrev: http://cr.openjdk.java.net/~bchristi/8205399/webrev01/
>     <http://cr.openjdk.java.net/~bchristi/8205399/webrev01/>
>
>     The vmTestbase/vm/gc/containers/Combination05/TestDescription.java
>     test, which does random adds and removes (via Iterator), has been
>     failing intermittently with an AssertionError.
>
>     I tracked down a couple sequences of operations that trigger the
>     assertion.  Sufficient HashMap collisions convert a bin to a tree,
>     and then values are deleted using Iterator.remove() (pinned node
>     deletion).
>
>     The condition that fails in HashMap.TreeNode.checkInvariants() is:
>
>       if (t.red && tl != null && tl.red && tr != null && tr.red)
>
>     A red TreeNode should not have two red children.
>
>     Many thanks to Doug Lea for providing the fix for the HashMap
>     red/black tree code.  The root node color needs to be set in this case.
>
>     Thanks,
>     -Brent
>
>


From xu.y.yin at oracle.com  Thu Aug  9 03:35:20 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 9 Aug 2018 11:35:20 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <b7f642a6-4b47-a3b1-e7bf-c797b4628293@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
 <b7f642a6-4b47-a3b1-e7bf-c797b4628293@oracle.com>
Message-ID: <7C42C8FE-E34B-48B0-9431-A859D9DEC9A7@oracle.com>

Hi, Roger

Many thanks for your review and comments, inline and updated new webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208483/webrev.05/

> On 8 Aug 2018, at 9:52 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Chris,
> 
> Each of these tests is going to spawn a new process (/othervm). That's a lot of overhead for a short test.

Thank you for checking this, actually used /othervm here is intentional to make object factories working correctly, I?m not sure why yet, just guess jtreg agentvm mode will affect object factory loader which caused object factory not working. For example, if I removed /othervm from LookupWithAnyAttrProp.java then run 'jtreg -agentvm -v:summary -testjdk:xxx -a LookupWithAnyAttrProp.java?, test will failed to complain lookup returned object is com.sun.jndi.dns.DnsContext instead of TestDnsObject, that was unexpected. (I used latest jtreg version with jdk12, same result)

> 
> Can these be written as TestNG tests so they run quicker and more tests be in a single source file
> and run in single VM?

That's a good idea, but per current tests situation, guess it?s hard, 2 points as below
1. As above mentioned, for factory related tests, we have to specify /othervm to make object factory working, that may not suitable for TestNG
2. Each test along with a .dns dump file, even the test logic are very close, the dumped messages maybe very different. If using TestNG 1 test file with multiple tests, it will be more complex to manage/maintain those dump files (like create/update dump file per test, search/load dump file when run each test etc.)

> 
> @Override should be on its own line so the method signature is on a line by itself too.
> Setup your IDE to use the formatting conventions and let it reformat.

Sure, fixed, changed my IDE to use that style

> 
> LookupFactoryBase.java: 67 / 84  - Be consistent about the form of messages,
>  I prefer the Expected xxx but found yyy form.   (no need to say it failed, it threw an exception).

Fixed as you suggested form

> 
> The imports should be before the comment with the jtreg test description.

Fixed, thanks

Regards,
Chris

> 
> Thanks, Roger
> 
> On 8/7/18 11:41 PM, Chris Yin wrote:
>> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>> 
>> Regards,
>> Chris
>> 
>>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Hi, Vyom
>>> 
>>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>> 
>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>> 
>>> Regards,
>>> Chris
>>> 
>>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>> 
>>>> .Thanks,
>>>> 
>>>> Vyom
>>>> 
>>>> 
>>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>>> Hi, Vyom
>>>>> 
>>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>> 
>>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>> 
>>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>> 
>>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>> 
>>>>> * @return The object created; null if an object cannot be created.
>>>>> * @exception Exception If this object factory encountered an exception
>>>>> * while attempting to create an object, and no other object factories are
>>>>> * to be tried.
>>>>> 
>>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>>> Same as above
>>>>> 
>>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>> 
>>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>> 
>>>>> Thanks & Regards,
>>>>> Chris
>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Vyom
>>>>>> 
>>>>>> 
>>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>> 
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Chris
> 


From matthias.baesken at sap.com  Thu Aug  9 07:07:45 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 9 Aug 2018 07:07:45 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com>
Message-ID: <eb8cfe1c47f04ef19534faca7e14feac@sap.com>

> Did we get to a conclusion on whether to have central infrastructure to
> read/parse the security property? As I recall, this one was originally
> proposed before the generalization of the networking solution. There are
> details related to trimming that would be better not to duplicate if
> possible.

Hi Alan / Chris ,

I am aware of  

https://bugs.openjdk.java.net/browse/JDK-8207846

where jdk.net.includeInExceptions   has been generalized to be used for other use cases than  exceptions in the networking area .
This  has been pushed in the meantine.

Could you point me to the other discussion, is there already a webrev posted for this ?

> 
> Also, I think one of my comments on the original patch is that we should
> get the style and line lengths a bit more consistent with the existing
> code (the patch added excessively long lines for example).
>

Sure I'll look into it !

Best regards, Matthias


> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Mittwoch, 8. August 2018 20:30
> To: Baesken, Matthias <matthias.baesken at sap.com>; Chris Hegarty
> <chris.hegarty at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; OpenJDK Dev list <security-
> dev at openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> On 07/08/2018 16:00, Baesken, Matthias wrote:
> > Ping ....  ??  , any reviews / comments ?
> Did we get to a conclusion on whether to have central infrastructure to
> read/parse the security property? As I recall, this one was originally
> proposed before the generalization of the networking solution. There are
> details related to trimming that would be better not to duplicate if
> possible.
> 
> Also, I think one of my comments on the original patch is that we should
> get the style and line lengths a bit more consistent with the existing
> code (the patch added excessively long lines for example).
> 
> -Alan.

From chris.hegarty at oracle.com  Thu Aug  9 09:02:28 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 Aug 2018 10:02:28 +0100
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <eb8cfe1c47f04ef19534faca7e14feac@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <1b80c11d-da9e-c788-eddf-d3f0955ab823@oracle.com>
 <eb8cfe1c47f04ef19534faca7e14feac@sap.com>
Message-ID: <F2EC6FCD-D09C-418C-8BCD-DBE2681A9A4C@oracle.com>

Matthias,

> On 9 Aug 2018, at 08:07, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> Did we get to a conclusion on whether to have central infrastructure to
>> read/parse the security property? As I recall, this one was originally
>> proposed before the generalization of the networking solution. There are
>> details related to trimming that would be better not to duplicate if
>> possible.
> 
> Hi Alan / Chris ,
> 
> I am aware of  
> 
> https://bugs.openjdk.java.net/browse/JDK-8207846
> 
> where jdk.net.includeInExceptions   has been generalized to be used for other use cases than  exceptions in the networking area .
> This  has been pushed in the meantine.
> 
> Could you point me to the other discussion, is there already a webrev posted for this ?

Given that 8207846 was being targeted to JDK 11, during RDP 1,
it was decided to keep the changes as minimal as possible. The
supporting implementation, that reads and parses the property,
remains in src/java.base/share/classes/sun/net/util/SocketExceptions.java.
Alan referred to this in one of the review comments for 8207846 [1].
If this mechanism is to be used outside of the networking area,
and I think it can, then the implementation in SocketExceptions
should probably be moved to some other more appropriate
internal package.

>> 
>> Also, I think one of my comments on the original patch is that we should
>> get the style and line lengths a bit more consistent with the existing
>> code (the patch added excessively long lines for example).
>> 
> 
> Sure I'll look into it !


-Chris.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054501.html

> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Alan Bateman <Alan.Bateman at oracle.com>
>> Sent: Mittwoch, 8. August 2018 20:30
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Chris Hegarty
>> <chris.hegarty at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>; Langer, Christoph
>> <christoph.langer at sap.com>; OpenJDK Dev list <security-
>> dev at openjdk.java.net>
>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>> 
>> On 07/08/2018 16:00, Baesken, Matthias wrote:
>>> Ping ....  ??  , any reviews / comments ?
>> Did we get to a conclusion on whether to have central infrastructure to
>> read/parse the security property? As I recall, this one was originally
>> proposed before the generalization of the networking solution. There are
>> details related to trimming that would be better not to duplicate if
>> possible.
>> 
>> Also, I think one of my comments on the original patch is that we should
>> get the style and line lengths a bit more consistent with the existing
>> code (the patch added excessively long lines for example).
>> 
>> -Alan.


From claes.redestad at oracle.com  Thu Aug  9 11:33:25 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 13:33:25 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
Message-ID: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>

Hi,

using the new ability to archive immutable heap graphs into the CDS 
archive, even archiving small things like the Integer.IntegerCache can 
be profitable.

Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8209120

For a default cache (256 elements), this change saves us ~1 million 
instructions. Applications that use -XX:AutoBoxCacheMax can profit 
further (and we can use this to stress test the archiving feature..)

The patch is built on top of and tested with Jiangli's patch for 
https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent to 
push this before that is in.

Thanks!

/Claes


From Alan.Bateman at oracle.com  Thu Aug  9 11:41:27 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 Aug 2018 12:41:27 +0100
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
Message-ID: <00e54c48-1255-cac2-d926-1b64abddfeca@oracle.com>

On 09/08/2018 12:33, Claes Redestad wrote:
> Hi,
>
> using the new ability to archive immutable heap graphs into the CDS 
> archive, even archiving small things like the Integer.IntegerCache can 
> be profitable.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>
> For a default cache (256 elements), this change saves us ~1 million 
> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
> further (and we can use this to stress test the archiving feature..)
>
> The patch is built on top of and tested with Jiangli's patch for 
> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent to 
> push this before that is in.
>
Nice! What would you think about testing a test to at least exercise 
combinations of AutoBoxCacheMax at dump time and run time.

-Alan


From scolebourne at joda.org  Thu Aug  9 11:42:41 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 9 Aug 2018 12:42:41 +0100
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
Message-ID: <CACzrW9D3xUiBS+ra_anyGStYjfE35j+RD2Ra=NBOUysRA_DcTA@mail.gmail.com>

On 9 August 2018 at 12:33, Claes Redestad <claes.redestad at oracle.com> wrote:
> using the new ability to archive immutable heap graphs into the CDS archive,
> even archiving small things like the Integer.IntegerCache can be profitable.

Interesting. I did consider caching some instances of `LocalDate` when
I was developing JSR-310 (say 1 year either side of the current date
at startup). Maybe an avenue to investigate in the future!

thanks
Stephen


>
> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>
> For a default cache (256 elements), this change saves us ~1 million
> instructions. Applications that use -XX:AutoBoxCacheMax can profit further
> (and we can use this to stress test the archiving feature..)
>
> The patch is built on top of and tested with Jiangli's patch for
> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent to push
> this before that is in.
>
> Thanks!
>
> /Claes
>

From claes.redestad at oracle.com  Thu Aug  9 12:58:53 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 14:58:53 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <CACzrW9D3xUiBS+ra_anyGStYjfE35j+RD2Ra=NBOUysRA_DcTA@mail.gmail.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <CACzrW9D3xUiBS+ra_anyGStYjfE35j+RD2Ra=NBOUysRA_DcTA@mail.gmail.com>
Message-ID: <550d22c5-2cfe-0c05-fff8-47e5a831b9f1@oracle.com>



On 2018-08-09 13:42, Stephen Colebourne wrote:
> On 9 August 2018 at 12:33, Claes Redestad<claes.redestad at oracle.com>  wrote:
>> using the new ability to archive immutable heap graphs into the CDS archive,
>> even archiving small things like the Integer.IntegerCache can be profitable.
> Interesting. I did consider caching some instances of `LocalDate` when
> I was developing JSR-310 (say 1 year either side of the current date
> at startup). Maybe an avenue to investigate in the future!

As long we stay invariant with system time, time zone etc.. LocalDates 
should be
fine.

Archives can potentially be long lived, however, so caching a range of 
LocalDates
that is centered around the system time when creating the archive might 
lead to
degrading startup over time. Not sure that's a pleasant property to have.

/Claes

From claes.redestad at oracle.com  Thu Aug  9 13:23:01 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 15:23:01 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <00e54c48-1255-cac2-d926-1b64abddfeca@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <00e54c48-1255-cac2-d926-1b64abddfeca@oracle.com>
Message-ID: <0237c49e-b754-4fa8-7fbc-a19ebb3ad468@oracle.com>

On 2018-08-09 13:41, Alan Bateman wrote:

> Nice! 

Thanks!

> What would you think about testing a test to at least exercise 
> combinations of AutoBoxCacheMax at dump time and run time.

I'll try adding something to the suite of CDS tests..

/Claes

From roger.riggs at oracle.com  Thu Aug  9 14:01:36 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 9 Aug 2018 10:01:36 -0400
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <7C42C8FE-E34B-48B0-9431-A859D9DEC9A7@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
 <b7f642a6-4b47-a3b1-e7bf-c797b4628293@oracle.com>
 <7C42C8FE-E34B-48B0-9431-A859D9DEC9A7@oracle.com>
Message-ID: <861afc95-efe7-e960-b4ff-59b94f1edac9@oracle.com>

Hi Chris,

looks fine now.? +1

On 8/8/18 11:35 PM, Chris Yin wrote:
> Hi, Roger
>
> Many thanks for your review and comments, inline and updated new webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208483/webrev.05/
>
>> On 8 Aug 2018, at 9:52 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Each of these tests is going to spawn a new process (/othervm). That's a lot of overhead for a short test.
> Thank you for checking this, actually used /othervm here is intentional to make object factories working correctly, I?m not sure why yet, just guess jtreg agentvm mode will affect object factory loader which caused object factory not working. For example, if I removed /othervm from LookupWithAnyAttrProp.java then run 'jtreg -agentvm -v:summary -testjdk:xxx -a LookupWithAnyAttrProp.java?, test will failed to complain lookup returned object is com.sun.jndi.dns.DnsContext instead of TestDnsObject, that was unexpected. (I used latest jtreg version with jdk12, same result)
yes, /othervm is needed to avoid interference with other tests
>> Can these be written as TestNG tests so they run quicker and more tests be in a single source file
>> and run in single VM?
> That's a good idea, but per current tests situation, guess it?s hard, 2 points as below
> 1. As above mentioned, for factory related tests, we have to specify /othervm to make object factory working, that may not suitable for TestNG
/othervm can be used with testng
> 2. Each test along with a .dns dump file, even the test logic are very close, the dumped messages maybe very different. If using TestNG 1 test file with multiple tests, it will be more complex to manage/maintain those dump files (like create/update dump file per test, search/load dump file when run each test etc.)
As a thought experiment, and perhaps worth a prototype and especially if 
there are more tests to write.

The testname/dns might need to be refactored out from the test class 
name, but if I understand
the local server case, it creates a new local server for each test with 
a new port and environment.
With no overlap between the test data, a clean separation between the 
tests at runtime may be possible
with not too much work.

Thanks, Roger


>
>> @Override should be on its own line so the method signature is on a line by itself too.
>> Setup your IDE to use the formatting conventions and let it reformat.
> Sure, fixed, changed my IDE to use that style
>
>> LookupFactoryBase.java: 67 / 84  - Be consistent about the form of messages,
>>   I prefer the Expected xxx but found yyy form.   (no need to say it failed, it threw an exception).
> Fixed as you suggested form
>
>> The imports should be before the comment with the jtreg test description.
> Fixed, thanks
>
> Regards,
> Chris
>
>> Thanks, Roger
>>
>> On 8/7/18 11:41 PM, Chris Yin wrote:
>>> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>>>
>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>>>
>>> Regards,
>>> Chris
>>>
>>>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>
>>>> Hi, Vyom
>>>>
>>>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>>>
>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>>>
>>>>> .Thanks,
>>>>>
>>>>> Vyom
>>>>>
>>>>>
>>>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>>>> Hi, Vyom
>>>>>>
>>>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>>>
>>>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>>>
>>>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>>>
>>>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>>>
>>>>>> * @return The object created; null if an object cannot be created.
>>>>>> * @exception Exception If this object factory encountered an exception
>>>>>> * while attempting to create an object, and no other object factories are
>>>>>> * to be tried.
>>>>>>
>>>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>>>> Same as above
>>>>>>
>>>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>>>
>>>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Chris
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Chris


From peter.levart at gmail.com  Thu Aug  9 15:32:58 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 9 Aug 2018 17:32:58 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
Message-ID: <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>

Hi Claes,

When is this archived cache created? Is it possible to create archived 
cache with java.lang.Integer.IntegerCache.high system property set to > 
127 ? Wouldn't then at runtime, when cache is initialized from such 
oversized archive and no java.lang.Integer.IntegerCache.high system 
property is specified, the resulting cache array be to big?

Perhaps you could allocate a copy of the prefix of the de-archived array 
in that case to release the unused Integer instances.

Regards, Peter

On 08/09/2018 01:33 PM, Claes Redestad wrote:
> Hi,
>
> using the new ability to archive immutable heap graphs into the CDS 
> archive, even archiving small things like the Integer.IntegerCache can 
> be profitable.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>
> For a default cache (256 elements), this change saves us ~1 million 
> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
> further (and we can use this to stress test the archiving feature..)
>
> The patch is built on top of and tested with Jiangli's patch for 
> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent to 
> push this before that is in.
>
> Thanks!
>
> /Claes
>


From peter.levart at gmail.com  Thu Aug  9 15:41:56 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 9 Aug 2018 17:41:56 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
Message-ID: <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>



On 08/09/2018 05:32 PM, Peter Levart wrote:
> Hi Claes,
>
> When is this archived cache created? Is it possible to create archived 
> cache with java.lang.Integer.IntegerCache.high system property set to 
> > 127 ? Wouldn't then at runtime, when cache is initialized from such 
> oversized archive and no java.lang.Integer.IntegerCache.high system 
> property is specified, the resulting cache array be to big?
>
> Perhaps you could allocate a copy of the prefix of the de-archived 
> array in that case to release the unused Integer instances.

There's danger when you overwrite a non-null @Stable field with another 
value that this new value will not be seen. Or is <clinit> code an 
exception where @Stable is not honored yet...

To mitigate this possibility, you could have two fields:

static Integer cache[];
static final Integer finalCache[];

The 'cache' field is archived and de-archived. The final result is set 
to 'cache' by overwriting and to 'finalCache'. The later is then also 
used in Integer.valueOf().

Peter

>
> Regards, Peter
>
> On 08/09/2018 01:33 PM, Claes Redestad wrote:
>> Hi,
>>
>> using the new ability to archive immutable heap graphs into the CDS 
>> archive, even archiving small things like the Integer.IntegerCache 
>> can be profitable.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>>
>> For a default cache (256 elements), this change saves us ~1 million 
>> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
>> further (and we can use this to stress test the archiving feature..)
>>
>> The patch is built on top of and tested with Jiangli's patch for 
>> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent 
>> to push this before that is in.
>>
>> Thanks!
>>
>> /Claes
>>
>


From jiangli.zhou at oracle.com  Thu Aug  9 16:12:34 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 9 Aug 2018 09:12:34 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
Message-ID: <bb048706-773d-02c8-1456-809d94c0313e@oracle.com>

Hi Claes,

The change on the VM side looks good! Hope to see more graphs like this 
in the initial java heap being discovered and archived.

Thanks!

Jiangli


On 8/9/18 4:33 AM, Claes Redestad wrote:
> Hi,
>
> using the new ability to archive immutable heap graphs into the CDS 
> archive, even archiving small things like the Integer.IntegerCache can 
> be profitable.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>
> For a default cache (256 elements), this change saves us ~1 million 
> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
> further (and we can use this to stress test the archiving feature..)
>
> The patch is built on top of and tested with Jiangli's patch for 
> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent to 
> push this before that is in.
>
> Thanks!
>
> /Claes
>


From claes.redestad at oracle.com  Thu Aug  9 16:17:52 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 18:17:52 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
Message-ID: <0f3c7900-c9a6-a83b-f824-61eee8d02408@oracle.com>

Hi Peter,


On 2018-08-09 17:32, Peter Levart wrote:
> Hi Claes,
>
> When is this archived cache created? 

The cache you build when dumping the archive is serialized, so java 
-Xshare:dump -XX:AutoBoxCacheMax=20000 would create an array with 20k 
elements in the archive...

> Is it possible to create archived cache with 
> java.lang.Integer.IntegerCache.high system property set to > 127 ? 

Yes. I'm going to add a test that all variants work though, as Alan 
suggested.

> Wouldn't then at runtime, when cache is initialized from such 
> oversized archive and no java.lang.Integer.IntegerCache.high system 
> property is specified, the resulting cache array be to big?
>
> Perhaps you could allocate a copy of the prefix of the de-archived 
> array in that case to release the unused Integer instances.

The array would be too big, true, but it's backed by the read-only data 
in the archive directly, so while the Objects might appear in a heap 
dump, creating them happens at no extra cost and keeping them shouldn't 
actually cause any real (rss) memory footprint (GC shouldn't be scanning 
the memory, either).

As accesses to the array is guarded by checking IntegerCache.high (and 
not cache.length) we won't return cached Integers outside of the 
requested range, either.

So unless I'm mistaken, defensively allocating a copy shouldn't be 
necessary.

/Claes


>
> Regards, Peter
>
> On 08/09/2018 01:33 PM, Claes Redestad wrote:
>> Hi,
>>
>> using the new ability to archive immutable heap graphs into the CDS 
>> archive, even archiving small things like the Integer.IntegerCache 
>> can be profitable.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>>
>> For a default cache (256 elements), this change saves us ~1 million 
>> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
>> further (and we can use this to stress test the archiving feature..)
>>
>> The patch is built on top of and tested with Jiangli's patch for 
>> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent 
>> to push this before that is in.
>>
>> Thanks!
>>
>> /Claes
>>
>


From claes.redestad at oracle.com  Thu Aug  9 16:28:14 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 18:28:14 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
Message-ID: <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>



On 2018-08-09 17:41, Peter Levart wrote:
>
> There's danger when you overwrite a non-null @Stable field with 
> another value that this new value will not be seen. Or is <clinit> 
> code an exception where @Stable is not honored yet...

Typically IntegerCache::<clinit> runs before JIT has even started, so I 
think we're OK even though the double-assignment is undefined. But it's 
a good question what happens in cases we're running AOTd code, so 
perhaps this pattern might be problematic in some future..
>
> To mitigate this possibility, you could have two fields:
>
> static Integer cache[];
> static final Integer finalCache[];
>
> The 'cache' field is archived and de-archived. The final result is set 
> to 'cache' by overwriting and to 'finalCache'. The later is then also 
> used in Integer.valueOf().

Right, this would be a cheap way to dispel any concerns here.

/Claes


From peter.levart at gmail.com  Thu Aug  9 16:38:56 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 9 Aug 2018 18:38:56 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
Message-ID: <8d6ecbac-7e6b-c4ea-c51c-6cd62432d6bb@gmail.com>



On 08/09/2018 06:28 PM, Claes Redestad wrote:
>
>
> On 2018-08-09 17:41, Peter Levart wrote:
>>
>> There's danger when you overwrite a non-null @Stable field with 
>> another value that this new value will not be seen. Or is <clinit> 
>> code an exception where @Stable is not honored yet...
>
> Typically IntegerCache::<clinit> runs before JIT has even started, so 
> I think we're OK even though the double-assignment is undefined. But 
> it's a good question what happens in cases we're running AOTd code, so 
> perhaps this pattern might be problematic in some future..

What if you run it with -Xcomp ? Would still be run by interpreter at 
startup?

Regards, Peter

>>
>> To mitigate this possibility, you could have two fields:
>>
>> static Integer cache[];
>> static final Integer finalCache[];
>>
>> The 'cache' field is archived and de-archived. The final result is 
>> set to 'cache' by overwriting and to 'finalCache'. The later is then 
>> also used in Integer.valueOf().
>
> Right, this would be a cheap way to dispel any concerns here.
>
> /Claes
>


From claes.redestad at oracle.com  Thu Aug  9 16:52:38 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 Aug 2018 18:52:38 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <8d6ecbac-7e6b-c4ea-c51c-6cd62432d6bb@gmail.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <8d6ecbac-7e6b-c4ea-c51c-6cd62432d6bb@gmail.com>
Message-ID: <617bbd73-4a34-d50e-3b7e-5bac523c20a8@oracle.com>



On 2018-08-09 18:38, Peter Levart wrote:
>
> On 08/09/2018 06:28 PM, Claes Redestad wrote:
>>
>>
>> On 2018-08-09 17:41, Peter Levart wrote:
>>>
>>> There's danger when you overwrite a non-null @Stable field with 
>>> another value that this new value will not be seen. Or is <clinit> 
>>> code an exception where @Stable is not honored yet...
>>
>> Typically IntegerCache::<clinit> runs before JIT has even started, so 
>> I think we're OK even though the double-assignment is undefined. But 
>> it's a good question what happens in cases we're running AOTd code, 
>> so perhaps this pattern might be problematic in some future..
>
> What if you run it with -Xcomp ? 

Works.

> Would still be run by interpreter at startup?

Yes, -Xcomp doesn't change when JIT threads start running; verified on a 
debug build that IntegerCache.<clinit> is executed by the interpreter 
even with -Xcomp

/Claes

From joe.darcy at oracle.com  Thu Aug  9 18:36:21 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 9 Aug 2018 11:36:21 -0700
Subject: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for
 8209304: Deprecate serialVersionUID fields in interfaces
In-Reply-To: <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com>
References: <73efda66-407d-1a3d-ca7a-82bea05e2611@oracle.com>
 <4d21ee43-6b82-8146-4c91-d621ec4927bd@oracle.com>
Message-ID: <f40b295b-5298-688a-57df-c80771558f43@oracle.com>

Hi Alan,

On 8/6/2018 11:12 PM, Alan Bateman wrote:
>
>
> On 06/08/2018 20:11, joe darcy wrote:
>> Hello,
>>
>> Various interfaces in the JDK extend Serializable and declare 
>> serialVersionUID fields. Such fields are ineffectual and 
>> @SuppressWarnings("serial") should be applied to such fields to 
>> suppress future planned serial lint checks (JDK-8202056).
>>
>> Most of the affected files are in the security-libs area with a 
>> handful in RMI and JNDI:
>>
>> ??? http://cr.openjdk.java.net/~darcy/8209024.0/
>>
>> Patch below. I'll fix-up the copyright years before any push.
> Is there a follow-on patch coming to deprecate these fields?
>
>

Filed 8209304: Deprecate serialVersionUID fields in interfaces; webrev 
for review:

 ??? http://cr.openjdk.java.net/~darcy/8209304.0/

Security libs team, for

src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java

I added a separate @Deprecated annotation for the serialVersionUID field 
even though the interface itself is already deprecated. That interface's 
javadoc states:

 ? 41? * @deprecated Sun JDK internal use only --- WILL BE REMOVED in a 
future
 ? 42? * release.

If you like, as part of this changeset I can upgrade (downgrade?) the 
@Deprecated annotation for this class to forRemoval=true.

Once that detail is sorted out, I'll create the corresponding CSR. 
(Since the java.lang.Deprecated annotation type is @Documented, adding, 
removing, or changing @Deprecated annotations is an interface change.)

Thanks,

-Joe


From brian.burkhalter at oracle.com  Thu Aug  9 20:56:21 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 9 Aug 2018 13:56:21 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
Message-ID: <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>

Hello,

The latest build + test runs with the .03 revision of this patch check out on AIX, Linux-x64, macOS, Solaris-sparc, and Windows-x64.

If there is a Reviewer available who approves of these changes then please do so.

Thanks,

Brian

On Aug 7, 2018, at 3:41 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Matthias,
> 
> Yes, that was intentional. From the documentation it looks as if the Linux / Solaris *64 functions in question are now legacy so I changed them for hopefully better consistency. I did not see any problems in building or testing with these changes. If someone knows these changes to be incorrect then I would appreciate being so informed.
> 
> Does this latest (.03) patch check out on AIX?
> 
> Thanks,
> 
> Brian
> 
> On Aug 7, 2018, at 3:12 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> small remark from my side ,  looks like you changed in
>> 
>> src/java.base/unix/native/libjava/TimeZone_md.c
>> 
>> src/java.base/unix/native/libjava/childproc.c
>> 
>> and
>> 
>> src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
>> 
>> at some places  dirent64  /  readdir64   to   dirent  /  readdir
>> in the linux/solaris  coding.
>> 
>> for example
>> 
>> TimeZone_md.c
>> 
>> 122 static char *
>> 123 findZoneinfoFile(char *buf, size_t size, const char *dir)
>> 124 {
>> 125     DIR *dirp = NULL;
>> 126     struct stat statbuf;
>> 127     struct dirent *dp = NULL;.
>> 
>> 
>> Was it intended  to  change for linux/solaris ?
> 


From ivan.gerasimov at oracle.com  Thu Aug  9 23:15:10 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 Aug 2018 16:15:10 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
Message-ID: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>

Hello!

Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros() are 
intrinsified by Hotspot, so the Java implementation of these is not too 
important.
However, they still can be improved by a tiny bit :)

Could you please help review the fix?

Bug: https://bugs.openjdk.java.net/browse/JDK-8209171
Webrev: http://cr.openjdk.java.net/~igerasim/8209171/00/webrev/
Benchmark for Integer: 
http://cr.openjdk.java.net/~igerasim/8209171/00/bench/int/MyBenchmark.java
Benchmark for Long: 
http://cr.openjdk.java.net/~igerasim/8209171/00/bench/long/MyBenchmark.java

The resulting code is both smaller and faster.  It may also help to warm 
up Integer.numberOfLeadingZeros() quicker.

On average, the new Integer.numberOfTrailingZeros() has got +11% to 
performance for -client and +1% for -server.
Long.numberOfTrailingZeros() is faster on 17% for -client and +20% for 
-server.

-- 
With kind regards,
Ivan Gerasimov


From joe.darcy at oracle.com  Thu Aug  9 23:20:43 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 09 Aug 2018 16:20:43 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
Message-ID: <5B6CCC4B.7070809@oracle.com>

Hi Ivan,

On which platforms were the benchmark numbers collected?

Thanks,

-Joe

On 8/9/2018 4:15 PM, Ivan Gerasimov wrote:
> Hello!
>
> Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros() are 
> intrinsified by Hotspot, so the Java implementation of these is not 
> too important.
> However, they still can be improved by a tiny bit :)
>
> Could you please help review the fix?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209171
> Webrev: http://cr.openjdk.java.net/~igerasim/8209171/00/webrev/
> Benchmark for Integer: 
> http://cr.openjdk.java.net/~igerasim/8209171/00/bench/int/MyBenchmark.java
> Benchmark for Long: 
> http://cr.openjdk.java.net/~igerasim/8209171/00/bench/long/MyBenchmark.java
>
> The resulting code is both smaller and faster.  It may also help to 
> warm up Integer.numberOfLeadingZeros() quicker.
>
> On average, the new Integer.numberOfTrailingZeros() has got +11% to 
> performance for -client and +1% for -server.
> Long.numberOfTrailingZeros() is faster on 17% for -client and +20% for 
> -server.
>


From igor.ignatyev at oracle.com  Thu Aug  9 23:24:24 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 9 Aug 2018 16:24:24 -0700
Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files
In-Reply-To: <d6e53c9c-1814-ff6a-c8a0-b6f4fba86721@oracle.com>
References: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com>
 <d6e53c9c-1814-ff6a-c8a0-b6f4fba86721@oracle.com>
Message-ID: <2D832B3E-851B-44ED-970C-24E77B74E967@oracle.com>

Hi David,

thanks for your review. I've updated copyright years and added the next comment in GathererFactory.java:
> +            // os-specific action set must be last, b/c they can kill the process 


regarding checking w/ the people operating their own farms, I agree it'd be nice to do for changes like this one, but I don't know a better channel to do other than an email to dev alias, which wouldn't be much different from this RFR. 

In this particular case, I expect the hosts in all test farms to have core dumping enabled and core dumps from crashes are, from my observations, used more frequently than dumps from timeouts, so it shouldn't cause big issues.

Thanks,
-- Igor

> On Aug 7, 2018, at 9:00 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Igor,
> 
> This all seems okay. However we probably need to check that the people operating their own build/test farms are okay with this change.
> 
> Don't forget to update copyright years.
> 
> Minor comment below ...
> 
> On 8/08/2018 7:19 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html
>>> 18 lines changed: 3 ins; 5 del; 10 mod;
>> Hi all,
>> could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part.
> 
> Can you add a comment in GathererFactory to explain that as well please.
> 
> Thanks,
> David
> 
>> NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly.
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8205687
>> webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html
>> Thanks,
>> -- Igor


From ivan.gerasimov at oracle.com  Thu Aug  9 23:45:07 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 Aug 2018 16:45:07 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <5B6CCC4B.7070809@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <5B6CCC4B.7070809@oracle.com>
Message-ID: <e60e20e9-749e-c492-9eac-e23889367a09@oracle.com>

Hi Joe!


On 8/9/18 4:20 PM, Joseph D. Darcy wrote:
> Hi Ivan,
>
> On which platforms were the benchmark numbers collected?
>
Ah, yes, should have mentioned that.
macOS 10.13.5 High Sierra, processor 3.1 GHz Intel Core i7

With kind regards,
Ivan

> Thanks,
>
> -Joe
>
> On 8/9/2018 4:15 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros() are 
>> intrinsified by Hotspot, so the Java implementation of these is not 
>> too important.
>> However, they still can be improved by a tiny bit :)
>>
>> Could you please help review the fix?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209171
>> Webrev: http://cr.openjdk.java.net/~igerasim/8209171/00/webrev/
>> Benchmark for Integer: 
>> http://cr.openjdk.java.net/~igerasim/8209171/00/bench/int/MyBenchmark.java
>> Benchmark for Long: 
>> http://cr.openjdk.java.net/~igerasim/8209171/00/bench/long/MyBenchmark.java
>>
>> The resulting code is both smaller and faster.  It may also help to 
>> warm up Integer.numberOfLeadingZeros() quicker.
>>
>> On average, the new Integer.numberOfTrailingZeros() has got +11% to 
>> performance for -client and +1% for -server.
>> Long.numberOfTrailingZeros() is faster on 17% for -client and +20% 
>> for -server.
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Fri Aug 10 00:13:58 2018
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Aug 2018 17:13:58 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
Message-ID: <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>

On Thu, Aug 9, 2018 at 4:15 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros() are
> intrinsified by Hotspot, so the Java implementation of these is not too
> important.
> However, they still can be improved by a tiny bit :)
>
> Could you please help review the fix?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209171
> Webrev: http://cr.openjdk.java.net/~igerasim/8209171/00/webrev/
> Benchmark for Integer: http://cr.openjdk.java.net/~ig
> erasim/8209171/00/bench/int/MyBenchmark.java
> Benchmark for Long: http://cr.openjdk.java.net/~ig
> erasim/8209171/00/bench/long/MyBenchmark.java
>
> The resulting code is both smaller and faster.  It may also help to warm
> up Integer.numberOfLeadingZeros() quicker.
>
> On average, the new Integer.numberOfTrailingZeros() has got +11% to
> performance for -client and +1% for -server.
> Long.numberOfTrailingZeros() is faster on 17% for -client and +20% for
> -server.


It seems to me the benchmark is not entirely fair to the old java
implementation, since the new one gets the benefit of the intrinsification
of  numberOfLeadingZeros.  A fairer comparison would use turn off
intrinsification of both.

I guess benchmarking on 32-bit platforms is  no longer relevant, given that
they are all legacy now.

From ivan.gerasimov at oracle.com  Fri Aug 10 00:27:17 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 Aug 2018 17:27:17 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
Message-ID: <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>

Hi Martin!

Thanks for taking a look!


On 8/9/18 5:13 PM, Martin Buchholz wrote:
>
>
> On Thu, Aug 9, 2018 at 4:15 PM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hello!
>
>     Integer.numberOfTrailingZeros() and Long.numberOfTrailingZeros()
>     are intrinsified by Hotspot, so the Java implementation of these
>     is not too important.
>     However, they still can be improved by a tiny bit :)
>
>     Could you please help review the fix?
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8209171
>     <https://bugs.openjdk.java.net/browse/JDK-8209171>
>     Webrev: http://cr.openjdk.java.net/~igerasim/8209171/00/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/00/webrev/>
>     Benchmark for Integer:
>     http://cr.openjdk.java.net/~igerasim/8209171/00/bench/int/MyBenchmark.java
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/00/bench/int/MyBenchmark.java>
>     Benchmark for Long:
>     http://cr.openjdk.java.net/~igerasim/8209171/00/bench/long/MyBenchmark.java
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/00/bench/long/MyBenchmark.java>
>
>     The resulting code is both smaller and faster.  It may also help
>     to warm up Integer.numberOfLeadingZeros() quicker.
>
>     On average, the new Integer.numberOfTrailingZeros() has got +11%
>     to performance for -client and +1% for -server.
>     Long.numberOfTrailingZeros() is faster on 17% for -client and +20%
>     for -server.
>
>
> It seems to me the benchmark is not entirely fair to the old java 
> implementation, since the new one gets the benefit of the 
> intrinsification of  numberOfLeadingZeros.  A fairer comparison would 
> use turn off intrinsification of both.
I did not use the intrinsified variants of numberOfLeadingZeros in the 
benchmark.

In the first (Integer) benchmark I copied/pasted the Java implementation 
of both Integer.numberOfLeadingZeros and Integer.bitCount.
In the second (Long) one, Long.numberOfLeadingZeros and Long.bitCount 
were also copied into the test with their original names, and Integer 
versions of the functions were copied as Integer_numberOfLeadingZeros 
and Integer_numberOfTrailingZeros.

The later one was not the original function 
Integer.numberOfTrailingZeros, but the new one, so the numbers of the 
second benchmark reflect changes in both classes: Integer and Long.
>
> I guess benchmarking on 32-bit platforms is  no longer relevant, given 
> that they are all legacy now.
I ran them on x64 (Intel Core i7 to be precise).

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Fri Aug 10 00:42:35 2018
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Aug 2018 17:42:35 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
Message-ID: <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>

On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> I did not use the intrinsified variants of numberOfLeadingZeros in the
> benchmark.
>

Oops! Should have looked more closely!

Did you know about
http://www.hackersdelight.org/hdcodetxt/ntz.c.txt

From xu.y.yin at oracle.com  Fri Aug 10 05:42:29 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 10 Aug 2018 13:42:29 +0800
Subject: [12] RFR 8208483: Add 5 JNDI tests to
 com/sun/jndi/dns/FactoryTests/
In-Reply-To: <861afc95-efe7-e960-b4ff-59b94f1edac9@oracle.com>
References: <AF190C3F-3997-46AB-BFB6-76DC448C9020@oracle.com>
 <125a5e07-e7f6-6f1c-320f-32a71b95918a@oracle.com>
 <14A7D0DF-F755-4ACB-92A4-E147C78591BD@oracle.com>
 <0b5bb52b-83be-35e6-6b72-6c72c4a86a12@oracle.com>
 <E30111A8-F918-4A49-8D14-0C27AA267297@oracle.com>
 <DC4AB1AB-9181-44A0-BDC5-ECF2AB5A5626@oracle.com>
 <b7f642a6-4b47-a3b1-e7bf-c797b4628293@oracle.com>
 <7C42C8FE-E34B-48B0-9431-A859D9DEC9A7@oracle.com>
 <861afc95-efe7-e960-b4ff-59b94f1edac9@oracle.com>
Message-ID: <F76ACE39-8C7E-4693-AE99-17AAF49F5298@oracle.com>

Thank you, Roger

> On 9 Aug 2018, at 10:01 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Chris,
> 
> looks fine now.  +1
> 
> On 8/8/18 11:35 PM, Chris Yin wrote:
>> Hi, Roger
>> 
>> Many thanks for your review and comments, inline and updated new webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208483/webrev.05/
>> 
>>> On 8 Aug 2018, at 9:52 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Each of these tests is going to spawn a new process (/othervm). That's a lot of overhead for a short test.
>> Thank you for checking this, actually used /othervm here is intentional to make object factories working correctly, I?m not sure why yet, just guess jtreg agentvm mode will affect object factory loader which caused object factory not working. For example, if I removed /othervm from LookupWithAnyAttrProp.java then run 'jtreg -agentvm -v:summary -testjdk:xxx -a LookupWithAnyAttrProp.java?, test will failed to complain lookup returned object is com.sun.jndi.dns.DnsContext instead of TestDnsObject, that was unexpected. (I used latest jtreg version with jdk12, same result)
> yes, /othervm is needed to avoid interference with other tests
>>> Can these be written as TestNG tests so they run quicker and more tests be in a single source file
>>> and run in single VM?
>> That's a good idea, but per current tests situation, guess it?s hard, 2 points as below
>> 1. As above mentioned, for factory related tests, we have to specify /othervm to make object factory working, that may not suitable for TestNG
> /othervm can be used with testng

Cool, thank you for the info, I will have a try, guess the only concern is whether /othervm could be applied to test method to avoid interference with others in same test class

>> 2. Each test along with a .dns dump file, even the test logic are very close, the dumped messages maybe very different. If using TestNG 1 test file with multiple tests, it will be more complex to manage/maintain those dump files (like create/update dump file per test, search/load dump file when run each test etc.)
> As a thought experiment, and perhaps worth a prototype and especially if there are more tests to write.

Sure, I will try to make some prototype at the same time to see whether that way will be better

> 
> The testname/dns might need to be refactored out from the test class name, but if I understand
> the local server case, it creates a new local server for each test with a new port and environment.
> With no overlap between the test data, a clean separation between the tests at runtime may be possible
> with not too much work.

Yes, your understanding is correct, just the real case seems a little complex to sort out

Thanks & Regards,
Chris

> 
> Thanks, Roger
> 
> 
>> 
>>> @Override should be on its own line so the method signature is on a line by itself too.
>>> Setup your IDE to use the formatting conventions and let it reformat.
>> Sure, fixed, changed my IDE to use that style
>> 
>>> LookupFactoryBase.java: 67 / 84  - Be consistent about the form of messages,
>>>  I prefer the Expected xxx but found yyy form.   (no need to say it failed, it threw an exception).
>> Fixed as you suggested form
>> 
>>> The imports should be before the comment with the jtreg test description.
>> Fixed, thanks
>> 
>> Regards,
>> Chris
>> 
>>> Thanks, Roger
>>> 
>>> On 8/7/18 11:41 PM, Chris Yin wrote:
>>>> Just one more minor revision to expand initContext() into test method for easier read, new webrev as below, thanks
>>>> 
>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.04/
>>>> 
>>>> Regards,
>>>> Chris
>>>> 
>>>>> On 7 Aug 2018, at 5:41 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>>> 
>>>>> Hi, Vyom
>>>>> 
>>>>> Thanks a lot for your comment, I didn?t realize it, sure, I moved this constant to LookupFactoryBase as you suggested and also abstract the same verify logic into base class as ?verifyLookupObjectAndValue?, hope that looks better, update new webrev as below, thanks
>>>>> 
>>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.03/
>>>>> 
>>>>> Regards,
>>>>> Chris
>>>>> 
>>>>>> On 7 Aug 2018, at 4:35 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> Overall latest code looks good to me, one minor comment did you consider moving  "private static final String ATTRIBUTE_VALUE = "1.2.4.1";" in "LookupFactoryBase" ? as both LookupWithAnyAttrProp & LookupWithAttrProp inherit "LookupFactoryBase".
>>>>>> 
>>>>>> .Thanks,
>>>>>> 
>>>>>> Vyom
>>>>>> 
>>>>>> 
>>>>>> On Monday 06 August 2018 03:02 PM, Chris Yin wrote:
>>>>>>> Hi, Vyom
>>>>>>> 
>>>>>>> Many thanks for your review and comments, inline and updated webrev as below, thanks
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~xyin/8208483/webrev.01/
>>>>>>> 
>>>>>>>> On 6 Aug 2018, at 4:12 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Chris,
>>>>>>>> 
>>>>>>>> 1-> DirAFactory.java, "getIbjectInstance" returns "null"  if it fails to construct object. I will suggest you to throw  some "RuntimeException" instead returning null. If you return null then caller of "getObjectInstance" had to check for null and it will end in lots of boilerplate code.
>>>>>>> ?getObjectInstance? methods are override from DirObjectFactory and ObjectFactory, per my understanding on javadoc, return null should indicate object cannot be created and allow other factories can be tried, feel free to let me know if I misunderstand something on the api doc, thanks
>>>>>>> 
>>>>>>> Paste a few javadoc here against ?getObjectInstance? method as below
>>>>>>> 
>>>>>>> * @return The object created; null if an object cannot be created.
>>>>>>> * @exception Exception If this object factory encountered an exception
>>>>>>> * while attempting to create an object, and no other object factories are
>>>>>>> * to be tried.
>>>>>>> 
>>>>>>>> 2-> DirTxtFactory.java same as "DirFactory.java?.
>>>>>>> Same as above
>>>>>>> 
>>>>>>>> 3-> In LookupWithAnyAttrProp/LookupWithAttrProp java create a constant for "1.2.4.1" and put one liner comment if possible. This is will help future maintainer to understand why we are comparing with this value.
>>>>>>> Sure, created constant for ?1.2.4.1? and put comment to explain that it?s pre defined attribute value of ?A?, thanks
>>>>>>> 
>>>>>>>> One generic comment, in most of the places i can see, you declared functions to throw generic exception "Exception",  please change it to specific  exception or list of specific exceptions if possible.
>>>>>>> Fixed, those generic exception are generated automatically through override method, I removed those unused throws Exception from xxxFactory.
>>>>>>> 
>>>>>>> Thanks & Regards,
>>>>>>> Chris
>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Vyom
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Monday 30 July 2018 02:08 PM, Chris Yin wrote:
>>>>>>>>> Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks
>>>>>>>>> 
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/>
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Chris
> 


From ecki at zusammenkunft.net  Fri Aug 10 06:05:55 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 10 Aug 2018 08:05:55 +0200
Subject: File Attributes from DirectoryStream (WindowsPathWithAttributes)?
Message-ID: <5b6d2b43.1c69fb81.dd4f7.2cf5@mx.google.com>

Hello,

in sun.nio.fs.WindowsDirectoryStream I see that the code which iterates the Directory goes to some length to retain the file attributes returned from that function (by attaching them to a WindowsPathWithAttributes (aka BasicFileAttributesHolder).

And indeed I can see that class in my DirectroyStream Iterator or Filter. However I do not see that the normal WindowsFilesystemProvider (or actually WindowsFileAttributes#get() check for instances of that. This way None of the Files.getAttributeView seem to Benefit from that.

So I wonder is this missing or is there some other way you are supposed to work with this cached Attributes?

For 8 I can work with instanceof, but that might no longer be an Option with JPMS.

Gruss
Bernd
-- 
http://bernd.eckenfels.net


From xu.y.yin at oracle.com  Fri Aug 10 09:04:59 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 10 Aug 2018 17:04:59 +0800
Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/
In-Reply-To: <DC4F9209-8A0A-4CBE-89B9-97603DD5E408@oracle.com>
References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com>
 <DC4F9209-8A0A-4CBE-89B9-97603DD5E408@oracle.com>
Message-ID: <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com>

Sorry... another minor revision to handle @Override line and imports place, new webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8208542/webrev.02/

Regards,
Chris

> On 8 Aug 2018, at 2:51 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Minor revision to address javadoc, initContext() expansion, vararg etc. webrev as below, thanks
> 
> http://cr.openjdk.java.net/~xyin/8208542/webrev.01/ 
> 
> Regards,
> Chris
> 
>> On 31 Jul 2018, at 2:39 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>> 
>> Please review the changes to add 4 JNDI tests to com/sun/jndi/dns/ListTests/ in OpenJDK, thanks
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8208542
>> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/
>> 
>> Regards,
>> Chris
> 


From xu.y.yin at oracle.com  Fri Aug 10 09:15:54 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 10 Aug 2018 17:15:54 +0800
Subject: [12] RFR 8200151: Add 8 JNDI tests to
 com/sun/jndi/dns/ConfigTests/
In-Reply-To: <A0464C7B-5214-4AB0-9446-9C2B96FD0CD9@oracle.com>
References: <9FD6703A-49E8-41D8-B527-8D0D09726EB0@oracle.com>
 <c34ea8df-8feb-e52a-ded9-5f8ab0dae7b2@oracle.com>
 <8961A4DD-5119-46BD-B2B4-A3162302CAF7@oracle.com>
 <7fc8c142-1047-84b3-a009-d06e39dc0e92@oracle.com>
 <A0464C7B-5214-4AB0-9446-9C2B96FD0CD9@oracle.com>
Message-ID: <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com>

Minor revision to address testbase javadoc, initContext() expansion, @Override line and imports place, new webrev as below, thanks

http://cr.openjdk.java.net/~xyin/8200151/webrev.02/

Regards,
Chris

> On 30 Jul 2018, at 5:08 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Thank you, Vyom
> 
> Regards,
> Chris
> 
>> On 30 Jul 2018, at 5:06 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>> 
>> Hi Chris,
>> 
>> Latest code looks good to me.
>> 
>> Thanks,
>> 
>> Vyom
>> 
>> On Friday 27 July 2018 01:12 PM, Chris Yin wrote:
>>> Hi, Vyom
>>> 
>>> Thank a lot for your review and comments, inline and update new webrev as below, thanks
>>> 
>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.01/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.01/>
>>> 
>>> 
>>>> On 26 Jul 2018, at 5:27 PM, vyom tewari <vyom.tewari at oracle.com <mailto:vyom.tewari at oracle.com>> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Thanks for writing the tests overall code looks good to me, below are few minor comments.
>>>> 
>>>> 1`-> Fix tag order, my Netbeans always complains :) .
>>> 
>>> Fixed, thanks
>>> 
>>>> 
>>>> 2->  you make AuthRecursiveBase class as public but i can not see it is being used outside,  i will suggest you to give the default access if possible.
>>> 
>>> Sure, changed it to default access now
>>> 
>>>> 
>>>> 3-> AuthTrue.java, change the message as follows
>>>> 
>>>> "Got exception as expected : " -> "Got expected exception: ?;
>>> 
>>> Fixed
>>> 
>>>> 
>>>> 
>>>> 4-> PortUnreachable.java , any specific reason for 1000ms or you just choose random value ? Please don't hard-code this specific value  create a  constant and use it . If possible put some comment why we choose 1 second, this will help in debugging if this test fails intermittently in future.
>>> 
>>> Sure, I created a constant ?THRESHOLD' for it, 1000ms will be used as a threshold value for this test, normally the request should fail very quick (in a few ms), but consider to different platform and test machine performance, we used an acceptable threshold here, some comments added to it in the code too, thanks
>>> 
>>>> 
>>>> 5-> Timeout.java, do you really need to set the env using "DNSTestUtils.initEnv" ?
>>>> 
>>>> I see, this test is not using the DNSServer and other environments variables which were set by "DNSTestUtils.initEnv()" or i am missing something.
>>> 
>>> Actually, it?s indeed not necessary, just set very few default value such as ?Context.INITIAL_CONTEXT_FACTORY? in the test code should be fine, but I may still want to keep the test consistency, then we could have better maintainability for those tests. Sorry, I forgot to refactor this test with testbase (actually, its not necessary too, but guess the consistent style and shared base/methods will make the test easy to read and maintain, refactored this test and PortUnreachable.java now)
>>> 
>>> Regards,
>>> Chris
>>> 
>>>> 
>>>> Thanks,
>>>> Vyom
>>>> 
>>>> On Wednesday 25 July 2018 02:41 PM, Chris Yin wrote:
>>>>> Please review the changes to add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ in OpenJDK, due to known issue 7164518, PortUnreachable.java will be problem list for 'macosx-all', thanks
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151> <https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151>>
>>>>> webrev: http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/> <http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/>>
>>>>> 
>>>>> Regards,
>>>>> Chris
>>>> 
>>> 
>> 
> 


From bsrbnd at gmail.com  Fri Aug 10 13:20:36 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 10 Aug 2018 15:20:36 +0200
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
Message-ID: <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>

Hi Brian,

Among the files you suggest to fix, only the following ones are still
using 'readdir64' for other systems than AIX:

http://cr.openjdk.java.net/~bpb/8207744/webrev.03/src/java.base/unix/native/libjava/UnixFileSystem_md.c.frames.html
http://cr.openjdk.java.net/~bpb/8207744/webrev.03/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c.frames.html

I think you could also use 'readdir' and remove lines like the
following ones in both files:

  67 #if defined(_ALLBSD_SOURCE)
  68   #define dirent64 dirent
  69   #define readdir64 readdir
  70   #define stat64 stat

The following file is the only one that uses 'readdir64' on BSD which
is suspect:

http://cr.openjdk.java.net/~bpb/8207744/webrev.03/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c.frames.html

I guess you could simply remove the following lines:

  77 #if defined(_ALLBSD_SOURCE)
  78   #define DIR DIR64
  79   #define dirent dirent64
  80   #define opendir opendir64
  81   #define closedir closedir64
  82   #define readdir readdir64
  83 #endif

In the following file:

http://cr.openjdk.java.net/~bpb/8207744/webrev.03/src/java.base/unix/native/libjava/TimeZone_md.c.frames.html

... 'readdir' seems not to be used on AIX, see:

  81 #if defined(__linux__) || defined(MACOSX) || defined(__solaris__)

So, some lines following '53 #if defined(_AIX) ...' are probably not necessary.

Finally, referring to [1], I note that 'readdir64' is only necessary
on Linux to access large file systems using 32-bit architectures:

"To support large filesystems on 32-bit machines there are LFS
variants of the last two functions."
[...]

So, removing it is OK if this feature isn't required by the JDK.

Cheers,
Bernard

[1] https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html


On 9 August 2018 at 22:56, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> Hello,
>
> The latest build + test runs with the .03 revision of this patch check out on AIX, Linux-x64, macOS, Solaris-sparc, and Windows-x64.
>
> If there is a Reviewer available who approves of these changes then please do so.
>
> Thanks,
>
> Brian
>
> On Aug 7, 2018, at 3:41 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> Hi Matthias,
>>
>> Yes, that was intentional. From the documentation it looks as if the Linux / Solaris *64 functions in question are now legacy so I changed them for hopefully better consistency. I did not see any problems in building or testing with these changes. If someone knows these changes to be incorrect then I would appreciate being so informed.
>>
>> Does this latest (.03) patch check out on AIX?
>>
>> Thanks,
>>
>> Brian
>>
>> On Aug 7, 2018, at 3:12 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
>>
>>> small remark from my side ,  looks like you changed in
>>>
>>> src/java.base/unix/native/libjava/TimeZone_md.c
>>>
>>> src/java.base/unix/native/libjava/childproc.c
>>>
>>> and
>>>
>>> src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
>>>
>>> at some places  dirent64  /  readdir64   to   dirent  /  readdir
>>> in the linux/solaris  coding.
>>>
>>> for example
>>>
>>> TimeZone_md.c
>>>
>>> 122 static char *
>>> 123 findZoneinfoFile(char *buf, size_t size, const char *dir)
>>> 124 {
>>> 125     DIR *dirp = NULL;
>>> 126     struct stat statbuf;
>>> 127     struct dirent *dp = NULL;.
>>>
>>>
>>> Was it intended  to  change for linux/solaris ?
>>
>

From claes.redestad at oracle.com  Fri Aug 10 13:32:35 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 10 Aug 2018 15:32:35 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
Message-ID: <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>


On 2018-08-09 18:28, Claes Redestad wrote:
>
>
> On 2018-08-09 17:41, Peter Levart wrote:
>>
>> There's danger when you overwrite a non-null @Stable field with 
>> another value that this new value will not be seen. Or is <clinit> 
>> code an exception where @Stable is not honored yet...
>
> Typically IntegerCache::<clinit> runs before JIT has even started, so 
> I think we're OK even though the double-assignment is undefined. But 
> it's a good question what happens in cases we're running AOTd code, so 
> perhaps this pattern might be problematic in some future..
>>
>> To mitigate this possibility, you could have two fields:
>>
>> static Integer cache[];
>> static final Integer finalCache[];
>>
>> The 'cache' field is archived and de-archived. The final result is 
>> set to 'cache' by overwriting and to 'finalCache'. The later is then 
>> also used in Integer.valueOf().
>
> Right, this would be a cheap way to dispel any concerns here.

New webrev: http://cr.openjdk.java.net/~redestad/8209120/open.01/

I've verified all cases I can think of manually, but would like to defer 
the creation of a sanity test to a follow-up RFE to allow time to think 
through and discussing how to best go about that (do we need to verify 
in depth, can we reuse some existing test etc..)

Thanks!

/Claes

From ioi.lam at oracle.com  Fri Aug 10 14:10:55 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 10 Aug 2018 07:10:55 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
Message-ID: <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>



> On Aug 10, 2018, at 6:32 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 
>> On 2018-08-09 18:28, Claes Redestad wrote:
>> 
>> 
>>> On 2018-08-09 17:41, Peter Levart wrote:
>>> 
>>> There's danger when you overwrite a non-null @Stable field with another value that this new value will not be seen. Or is <clinit> code an exception where @Stable is not honored yet...
>> 
>> Typically IntegerCache::<clinit> runs before JIT has even started, so I think we're OK even though the double-assignment is undefined. But it's a good question what happens in cases we're running AOTd code, so perhaps this pattern might be problematic in some future..
>>> 
>>> To mitigate this possibility, you could have two fields:
>>> 
>>> static Integer cache[];
>>> static final Integer finalCache[];
>>> 
>>> The 'cache' field is archived and de-archived. The final result is set to 'cache' by overwriting and to 'finalCache'. The later is then also used in Integer.valueOf().
>> 
>> Right, this would be a cheap way to dispel any concerns here.
> 
> New webrev: http://cr.openjdk.java.net/~redestad/8209120/open.01/
> 
> I've verified all cases I can think of manually, but would like to defer the creation of a sanity test to a follow-up RFE to allow time to think through and discussing how to best go about that (do we need to verify in depth, can we reuse some existing test etc..)
> 

I think it?s better to include a good test case in this REF, especially since object archiving is a new feature.

Thanks
Ioi

> Thanks!
> 
> /Claes


From mandy.chung at oracle.com  Fri Aug 10 15:01:29 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 10 Aug 2018 08:01:29 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
Message-ID: <3597eb75-7358-0353-5199-8caed7e12145@oracle.com>



On 8/10/18 6:32 AM, Claes Redestad wrote:
> 
> On 2018-08-09 18:28, Claes Redestad wrote:
>>
>>
>> On 2018-08-09 17:41, Peter Levart wrote:
>>>
>>> There's danger when you overwrite a non-null @Stable field with 
>>> another value that this new value will not be seen. Or is <clinit> 
>>> code an exception where @Stable is not honored yet...
>>
>> Typically IntegerCache::<clinit> runs before JIT has even started, so 
>> I think we're OK even though the double-assignment is undefined. But 
>> it's a good question what happens in cases we're running AOTd code, so 
>> perhaps this pattern might be problematic in some future..
>>>
>>> To mitigate this possibility, you could have two fields:
>>>
>>> static Integer cache[];
>>> static final Integer finalCache[];
>>>
>>> The 'cache' field is archived and de-archived. The final result is 
>>> set to 'cache' by overwriting and to 'finalCache'. The later is then 
>>> also used in Integer.valueOf().
>>
>> Right, this would be a cheap way to dispel any concerns here.
> 
> New webrev: http://cr.openjdk.java.net/~redestad/8209120/open.01/

This looks good to me.   Similar pattern may also be applied
to empty ListN, SetN, MapN added by JDK-8207263.

Mandy

From scolebourne at joda.org  Fri Aug 10 15:23:52 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 10 Aug 2018 16:23:52 +0100
Subject: Deprecate java.io.File or at least some methods
In-Reply-To: <2059554422.30112.1533557728907.JavaMail.zimbra@u-pem.fr>
References: <2059554422.30112.1533557728907.JavaMail.zimbra@u-pem.fr>
Message-ID: <CACzrW9B81mJGD8PjiS6L6rd=8ORxgGNLfSnhKjNMnXeBtLLTrA@mail.gmail.com>

>From what I can see, File is more widely used than Path. Thats partly
because using Path is non-obvious - it doesn't have any methods for
doing anything.

I've suggested before that a default method could be added, so you get

 path.operations().isReadable()
 path.operations().readAllBytes()
 path.operations().delete()

which would make `Path` more palatable for general use.

Stephen


On 6 August 2018 at 13:15, Remi Forax <forax at univ-mlv.fr> wrote:
> Hi all,
> restarting discussion about JDK-8181098,
> java.io.File has several severe issues so we should alert users to migrate to use java.nio.file.[Path|Files] ASAP using the deprecation mechanism (obviously not for removal).
>
> The usual gotchas
> - File used string name which may do not map correctly with the underlying file system charset.
> - methods that are developer hostile
>   - methods that performs an action on the file system file returns a false if there is an issue instead of an IOException
>   - methods that list files return null instead of an IOException if there is an issue.
> - reading/writing into a file (using File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8.
>
> I see two ways of deprecation, one is to deprecate the whole class, it has the advantage of making the things clear, the other is to deprecate the constructors and all methods that acts on the file of the file system. The later option allows library to still have methods that takes a java.io.File as parameter if their implementation use toPath() to perform the operations.
>
> regards,
> R?mi
>
>
>
>
>

From claes.redestad at oracle.com  Fri Aug 10 15:44:06 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 10 Aug 2018 17:44:06 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
 <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
Message-ID: <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>

On 2018-08-10 16:10, Ioi Lam wrote:
>> I've verified all cases I can think of manually, but would like to defer the creation of a sanity test to a follow-up RFE to allow time to think through and discussing how to best go about that (do we need to verify in depth, can we reuse some existing test etc..)
>>
> I think it?s better to include a good test case in this REF, especially since object archiving is a new feature.

Well, I'm not sure about "good", but I have a test case I've tinkered 
with that simply tests that identity of Integer.valueOf behaves as 
expected w.r.t. Object identity around the break-off point. I'm 
pondering if we need to inspect the archived values more deeply, but 
perhaps it's good enough as a sanity test for now:

http://cr.openjdk.java.net/~redestad/8209120/open.02/

WDYT?

/Claes

From sean.mullan at oracle.com  Fri Aug 10 15:39:24 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 10 Aug 2018 11:39:24 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
Message-ID: <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>

I need more time to finish my review but here are some initial comments:

- java.security

1079 #  jarpath - enables more detailed information in the IOExceptions 
thrown

Use "jarPath" to be consistent with "hostInfo".

1080 #            by java.util.jar.Attributes  and java.util.jar.Manifest

and java.util.jar.JarFile

- Manifest.java

57     private String jarFilename = null;

Not necessary to set it to null, as that is the default.

   82     Manifest(InputStream is, String jarFilename) throws IOException {
   83         this.jarFilename = jarFilename;
   84         read(is);
   85     }

Read from the InputStream and check for error conditions *before* 
setting jarFilename (switch lines 83 & 84). This is a general best 
practice but can also protect against finalizer attacks. See JSCG 7-3 
for more info: 
https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7

- Attributes.java

As Chris and Alan mentioned, you should move the parsing of the property 
to a more general location so it can be used by other code that uses 
this property.

--Sean

On 8/8/18 11:00 AM, Sean Mullan wrote:
> Cross-posting to security-dev since this fix is security related and 
> should also be reviewed there.
> 
> --Sean
> 
> On 8/7/18 11:00 AM, Baesken, Matthias wrote:
>> Ping ....? ??? , any reviews / comments ?
>>
>> Thanks , Matthias
>>
>>> -----Original Message-----
>>> From: Baesken, Matthias
>>> Sent: Dienstag, 31. Juli 2018 12:28
>>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; Alan Bateman
>>> <Alan.Bateman at oracle.com>
>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
>>> <goetz.lindenmaier at sap.com>; Langer, Christoph
>>> <christoph.langer at sap.com>
>>> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest
>>> parsing of jar archives
>>>
>>> Hello ,
>>> looks like? the? generalization of? the `includeInExceptions` 
>>> security?? property
>>> is now in jdk/jdk? after
>>>
>>> "8207846: Generalize the jdk.net.includeInExceptions security property"
>>>
>>> was added, great news? and thanks to Chris for driving this !
>>>
>>> I use this security property now as well , and updated the? change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
>>>
>>> I updated the CSR as well :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8207768
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Chris Hegarty <chris.hegarty at oracle.com>
>>>> Sent: Donnerstag, 19. Juli 2018 14:54
>>>> To: Alan Bateman <Alan.Bateman at oracle.com>; Baesken, Matthias
>>>> <matthias.baesken at sap.com>
>>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com>
>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>>>> parsing of jar archives
>>>>
>>>>
>>>>> On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com>
>>>> wrote:
>>>>>
>>>>> On 19/07/2018 09:07, Baesken, Matthias wrote:
>>>>>> Hello, in the meantime I? prepared a CSR :
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768
>>>>>>
>>>>>>
>>>>>>> jdk.includeInExceptions expands the scope. That might be okay but we
>>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the
>>>>>>> support to somewhere in jdk.internal so that it can be used by other
>>>>>>> code in java.base.
>>>>>> Is there some support code for? " jdk.net.includeInExceptions "    
>>>>>> or do
>>>> you just? mean? the name of the property ?
>>>>>>
>>>>> Chris is right that it's a bit premature to submit a CSR while the 
>>>>> question
>>> on
>>>> whether to rename the existing security property is on the table. I 
>>>> have no
>>>> objection to doing that.
>>>>
>>>> I filed the following issue to generalize the `includeInExceptions` 
>>>> security
>>>> ? property:
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8207846
>>>>
>>>> I would like to resolve 8207846 first, then 8205525 can propose to 
>>>> add the
>>>> new argument value, `jarPath`.
>>>>
>>>> -Chris.

From adam.farley at uk.ibm.com  Fri Aug 10 15:42:00 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 10 Aug 2018 16:42:00 +0100
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
Message-ID: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>

Hi All,

This bug could be fixed by comparing the Class Loader with a blank 
static volatile Object (defined outside the method scope) at the 
end of the getBundleImpl class.

E.g.

-----------------------------------------
+1322
    /**
     * volatile reference object to guard the ClassLoader object
     * being garbage collected before getBundleImpl() method completes
     * the caching and retrieving of requested Resourcebundle object
     */
    private static volatile Object vo = new Object();


+1400
//Should never be true. Using the loader here prevents it being GC'd.
            if (loader == vo) throw new Error("Unexpected error.");
-----------------------------------------

Will upload a webrev after debate.

- Adam
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From ioi.lam at oracle.com  Fri Aug 10 15:52:31 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 10 Aug 2018 08:52:31 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
 <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
 <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
Message-ID: <24a26541-bdfb-00cc-c454-453a0cb76998@oracle.com>



On 8/10/18 8:44 AM, Claes Redestad wrote:
> On 2018-08-10 16:10, Ioi Lam wrote:
>>> I've verified all cases I can think of manually, but would like to defer the creation of a sanity test to a follow-up RFE to allow time to think through and discussing how to best go about that (do we need to verify in depth, can we reuse some existing test etc..)
>>>
>> I think it?s better to include a good test case in this REF, especially since object archiving is a new feature.
>
> Well, I'm not sure about "good", but I have a test case I've tinkered 
> with that simply tests that identity of Integer.valueOf behaves as 
> expected w.r.t. Object identity around the break-off point. I'm 
> pondering if we need to inspect the archived values more deeply, but 
> perhaps it's good enough as a sanity test for now:
>
> http://cr.openjdk.java.net/~redestad/8209120/open.02/
>
> WDYT?
>
Hi Claes,

Thanks for writing these tests. They look "good" to me :-).

If I understand Peter's comments correctly, the main concern is that the 
runtime configurations may be different than what you have at dump time. 
These tests seem to sufficiently cover such differences.

Thanks
- Ioi


> /Claes


From adam.farley at uk.ibm.com  Fri Aug 10 15:58:30 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 10 Aug 2018 16:58:30 +0100
Subject: RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for
 Direct Byte Buffers
Message-ID: <OF217D83C3.02CAC531-ON002582E5.00573175-802582E5.0057C136@notes.na.collabserv.com>

-- Bump --


Hi Folks,

> Zhengyu Gu <zgu at redhat.com> wrote on 06/06/2018 01:58:18:

> From: Zhengyu Gu <zgu at redhat.com>
> To: "Thomas St?fe" <thomas.stuefe at gmail.com>, Adam Farley8 
> <adam.farley at uk.ibm.com>
> Cc: "hotspot-dev at openjdk.java.net developers" <hotspot-
> dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>
> Date: 06/06/2018 01:58
> Subject: Re: RFR Bug-pending: Enable Hotspot to Track Native Memory 
> Usage for Direct Byte Buffers
> 
> On 06/05/2018 12:10 PM, Thomas St?fe wrote:> On Tue, Jun 5, 2018 at 3:46 

> PM, Adam Farley8 <adam.farley at uk.ibm.com> wrote:
> >> Hi All,
> >>
> >> Native memory allocation for DBBs is tracked in java.nio.Bits, but 
that
> >> only includes what the user thinks they are allocating.
> >>
> > 
> > Which is exactly what I would expect as a user...

A debugger poring over the values in the file may prefer total accuracy in 
at
least one of the variables, so they can find out where all their memory
went in the event of a leak. Even if this variable is not accessible via
a getter method, and is only readable via a system core.

> > 
> 
> I agree with Thomas, there is no point for a user to aware of tracking 
> overhead, and the overhead only incurs when native memory tracking is 
> on. As a matter of fact, it can really confuse user that values can be 
> varied, depending on whether native memory tracking is on.
> 
> Thanks,
> 
> -Zhengyu

I agree that the casual user shouldn't have to worry. This accuracy would 
be
for analysis after the fact, via system cores. The standard variables can 
stay 
as they are. I suggest the addition of a single AtomicLong that shows an
accurate value for the sole purpose of aiding debugging.

> 
> 
> >> When the VM adds extra memory to the allocation amount this extra bit 
is
> >> not represented in the Bits total. A cursory glance
> >> shows, minimum, that we round the requested memory quantity up to the 
heap
> >> word size in the Unsafe.allocateMemory code
> > 
> > which I do not understand either - why do we do this? After all,
> > normal allocations from inside hotspot do not get aligned up in size,
> > and the java doc to Unsafe allocateMemory does not state anything
> > about the size being aligned.
> > 
> > In addition to questioning the align up of the user requested size, I
> > would be in favor of adding a new NMT tag for these, maybe "mtUnsafe"?
> > That would be an easy fix.
> > 
> >> , and
> >> something to do with nmt_header_size in os:malloc() (os.cpp) too.
> > 
> > That is mighty unspecific and also wrong. The align-up mentioned above
> > goes into the size reported by Bits; the nmt header size does not.
> > 

I believe we agree here too. My point is that, for the sake of accuracy,
we *should* have this information in Bits. This is part of the 
debugger-aid 
change that I am suggesting.

> >>
> >> On its own, and in small quantities, align_up(sz, HeapWordSize) isn't 
that
> >> big of an issue. But when you allocate a lot of DBBs,
> >> and coupled with the nmt_header_size business, it makes the Bits 
values
> >> wrong. The more DBB allocations, the more inaccurate those
> >> numbers will be.
> > 
> > To be annoyingly precise, it will never be more wrong than 1:7 on
> > 64bit machines :) - if all memory requested via Unsafe.allocateMemory
> > would be of size 1 byte.

Sounds like the sort of thing I'd do. Once a stress tester, always a 
stress tester. :)

> > 
> >>
> >> To get the "+X", it seems to me that the best option would be to 
introduce
> >> an native method in Bits that fetches "X" directly
> >> from Hotspot, using the same code that Hotspot uses (so we'd have to
> >> abstract-out the Hotspot logic that adds X to the memory
> >> quantity). This way, anyone modifying the Hotspot logic won't risk
> >> rendering the Bits logic wrong again.
> > 
> > I don't follow that.

I was trying to describe one method to enable the VM to tell Bits how much
memory will actually be reserved for a given amount of DBB. E.g.
Bits says it has a DBB 7 bytes in size, and it tells the VM. The VM 
replies
with "OK, if you came to me and asked for 7 bytes, I'd reserve 8.", and 
then
Bits can update that debugging variable I mentioned.

If we abstract out the logic, then Bits and the VM would be using the 
exact 
same code when telling Bits how much memory will *hypothetically* be 
added,
as we do when the VM is determining how much overhead it needs when 
actually 
reserving the memory.

Is that clearer?

> > 
> >>
> >> That's only one way to fix the accuracy problem here though. 
Suggestions
> >> welcome.
> > 
> > You are throwing two effects together:
> > 
> > - As mentioned above, I consider the align-up of the user requested
> > size to be at least questionable. It shows up as user size in NMT
> > which should not be. I also fail to see a compelling reason for it,
> > but maybe someone else can enlighten me.

Well, if we got rid of it then that's one way to make the Bits variables
accurate. :)

> > 
> > - But anything else - NMT headers, overwriter guards, etc added by the
> > VM I consider in the same class as any other overhead incurred e.g. by
> > the CRT or the OS when calling malloc (e.g. malloc allocator bucket
> > size). Basically, rss will go up by more than size requested by
> > malloc. Something maybe worth noting, but IMHO not as part of the
> > numbers returned by java.nio.Bits.

We agree again. No need to confuse things by altering the return values. 
Simply store the accurate information internally as a debugging aid.

> > 
> > Just my 2 cents.

And they are appreciated. Apologies for the delay in my response.

- Adam

> > 
> > Best Regards, Thomas
> > 
> >>
> >> Best Regards
> >>
> >> Adam Farley
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with 
number
> >> 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From garydgregory at gmail.com  Fri Aug 10 16:46:43 2018
From: garydgregory at gmail.com (Gary Gregory)
Date: Fri, 10 Aug 2018 10:46:43 -0600
Subject: Deprecate java.io.File or at least some methods
In-Reply-To: <CACzrW9B81mJGD8PjiS6L6rd=8ORxgGNLfSnhKjNMnXeBtLLTrA@mail.gmail.com>
References: <2059554422.30112.1533557728907.JavaMail.zimbra@u-pem.fr>
 <CACzrW9B81mJGD8PjiS6L6rd=8ORxgGNLfSnhKjNMnXeBtLLTrA@mail.gmail.com>
Message-ID: <CACZkXPzH00MytRxSbKn0JHEZn2RV4=zDyoTh5T50NyAgPfw8uQ@mail.gmail.com>

On Fri, Aug 10, 2018, 09:25 Stephen Colebourne <scolebourne at joda.org> wrote:

> From what I can see, File is more widely used than Path. Thats partly
> because using Path is non-obvious - it doesn't have any methods for
> doing anything.
>
> I've suggested before that a default method could be added, so you get
>
>  path.operations().isReadable()
>  path.operations().readAllBytes()
>  path.operations().delete()
>
> which would make `Path` more palatable for general use.
>

+1!

Gary

>
> Stephen
>
>
> On 6 August 2018 at 13:15, Remi Forax <forax at univ-mlv.fr> wrote:
> > Hi all,
> > restarting discussion about JDK-8181098,
> > java.io.File has several severe issues so we should alert users to
> migrate to use java.nio.file.[Path|Files] ASAP using the deprecation
> mechanism (obviously not for removal).
> >
> > The usual gotchas
> > - File used string name which may do not map correctly with the
> underlying file system charset.
> > - methods that are developer hostile
> >   - methods that performs an action on the file system file returns a
> false if there is an issue instead of an IOException
> >   - methods that list files return null instead of an IOException if
> there is an issue.
> > - reading/writing into a file (using
> File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8.
> >
> > I see two ways of deprecation, one is to deprecate the whole class, it
> has the advantage of making the things clear, the other is to deprecate the
> constructors and all methods that acts on the file of the file system. The
> later option allows library to still have methods that takes a java.io.File
> as parameter if their implementation use toPath() to perform the operations.
> >
> > regards,
> > R?mi
> >
> >
> >
> >
> >
>

From jonathan.gibbons at oracle.com  Fri Aug 10 17:00:38 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 10 Aug 2018 10:00:38 -0700
Subject: Deprecate java.io.File or at least some methods
In-Reply-To: <CACzrW9B81mJGD8PjiS6L6rd=8ORxgGNLfSnhKjNMnXeBtLLTrA@mail.gmail.com>
References: <2059554422.30112.1533557728907.JavaMail.zimbra@u-pem.fr>
 <CACzrW9B81mJGD8PjiS6L6rd=8ORxgGNLfSnhKjNMnXeBtLLTrA@mail.gmail.com>
Message-ID: <5B6DC4B6.7010600@oracle.com>

I'd venture to suggest File is more widely used because it was around
from the beginning, whereas Path is significantly more recent.

Once you know to look on the Files API, using Path is generally easy
and way preferable.

-- Jon

On 08/10/2018 08:23 AM, Stephen Colebourne wrote:
>  From what I can see, File is more widely used than Path. Thats partly
> because using Path is non-obvious - it doesn't have any methods for
> doing anything.
>
> I've suggested before that a default method could be added, so you get
>
>   path.operations().isReadable()
>   path.operations().readAllBytes()
>   path.operations().delete()
>
> which would make `Path` more palatable for general use.
>
> Stephen
>
>
> On 6 August 2018 at 13:15, Remi Forax <forax at univ-mlv.fr> wrote:
>> Hi all,
>> restarting discussion about JDK-8181098,
>> java.io.File has several severe issues so we should alert users to migrate to use java.nio.file.[Path|Files] ASAP using the deprecation mechanism (obviously not for removal).
>>
>> The usual gotchas
>> - File used string name which may do not map correctly with the underlying file system charset.
>> - methods that are developer hostile
>>    - methods that performs an action on the file system file returns a false if there is an issue instead of an IOException
>>    - methods that list files return null instead of an IOException if there is an issue.
>> - reading/writing into a file (using File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8.
>>
>> I see two ways of deprecation, one is to deprecate the whole class, it has the advantage of making the things clear, the other is to deprecate the constructors and all methods that acts on the file of the file system. The later option allows library to still have methods that takes a java.io.File as parameter if their implementation use toPath() to perform the operations.
>>
>> regards,
>> R?mi
>>
>>
>>
>>
>>


From jiangli.zhou at oracle.com  Fri Aug 10 17:15:29 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 10 Aug 2018 10:15:29 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
 <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
 <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
Message-ID: <ff8865ec-7c41-1b13-cfd0-f1c713af910f@oracle.com>

Hi Claes,

The updated Integer.java looks good. The test also looks good to me. I'd 
suggest adding some checks in CheckIntegerCacheApp test for the cached 
Integers using WhiteBox API, WhiteBox.isShared(object) to make sure that 
they are archived. Checking all cached Integers is probably too 
excessive and unnecessary. Select a few values within [-128, 127] range 
would be good enough, I think.

As archived java heap data mapping may fail in some cases at runtime, 
and there is no need to continue the test execution when that happens as 
it would not exercise any of the archived java objects. The following 
can be done at the beginning of CheckIntegerCacheApp:

 ??????? WhiteBox wb = WhiteBox.getWhiteBox();

 ??????? if (!wb.areOpenArchiveHeapObjectsMapped()) {
 ??????????? return;
 ??????? }

Thanks!

Jiangli

On 8/10/18 8:44 AM, Claes Redestad wrote:
> On 2018-08-10 16:10, Ioi Lam wrote:
>>> I've verified all cases I can think of manually, but would like to 
>>> defer the creation of a sanity test to a follow-up RFE to allow time 
>>> to think through and discussing how to best go about that (do we 
>>> need to verify in depth, can we reuse some existing test etc..)
>>>
>> I think it?s better to include a good test case in this REF, 
>> especially since object archiving is a new feature.
>
> Well, I'm not sure about "good", but I have a test case I've tinkered 
> with that simply tests that identity of Integer.valueOf behaves as 
> expected w.r.t. Object identity around the break-off point. I'm 
> pondering if we need to inspect the archived values more deeply, but 
> perhaps it's good enough as a sanity test for now:
>
> http://cr.openjdk.java.net/~redestad/8209120/open.02/
>
> WDYT?
>
> /Claes


From joe.darcy at oracle.com  Fri Aug 10 17:39:47 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 10 Aug 2018 10:39:47 -0700
Subject: Initial JDK 11 RFR of JDK-8202385: Annotation to mark
 serial-related fields and methods
In-Reply-To: <788c428b-f4da-ad0d-6bc1-c5a8092d1c51@Oracle.com>
References: <0fc9f7bf-120a-ff7d-1119-acfe233a00c2@oracle.com>
 <234afda3-7ba2-88d7-22d9-1c08b4667e48@Oracle.com>
 <d4078a24-653c-e25d-89f4-d9526519f807@oracle.com>
 <7905537a-659b-6dfe-bb8c-4c8aefda2b02@oracle.com>
 <788c428b-f4da-ad0d-6bc1-c5a8092d1c51@Oracle.com>
Message-ID: <970afff0-ac0a-6f62-78c9-06595834a6ea@oracle.com>

Hi Roger,

Returning to this topic, I'll add a clause in the spec for 
serialPersistentFields and Externalizable and corresponding code in the 
checker. Should there be a similar check for serialVersionUID in an 
Externalizable class? It wasn't clear to me from reading the specs and 
there are cases in the JDK of classes implementing Externalizable and 
having serialVersionUID fields defined.

Thanks,

-Joe


On 5/10/2018 2:26 PM, Roger Riggs wrote:
> Hi Joe,
>
> The words are fine.
>
> The field serialPersistentFields is also not used with @Externalizable.
>
> I would guess the lint checker would flag those methods and field for 
> warnings for Externalizable classes
> since they might mislead to think they were used.
>
> Roger
>
>
> On 5/10/2018 5:03 PM, joe darcy wrote:
>> PS After additional reading, I propose to add the follow clause to 
>> where using the annotation is not appropriate:
>>
>> ?* <li>the {@code writeObject}, {@code readObject}, and {@code
>> ?* readObjectNoData} methods in a class that is {@code
>> ?* Externalizable}. While the {@code Externalizable} interface extends
>> ?* {@code Serializable}, those three methods are not used for
>> ?* externalizable classes.
>>
>> How does that sound?
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> On 5/10/2018 1:22 PM, joe darcy wrote:
>>> Hi Roger,
>>>
>>> Right; there are a few other distinguished methods defined for 
>>> externalization, but they are defined on the as methods on the 
>>> Externalizable interface as far as I can tell. The existence of 
>>> externalization is mentioned in the javac lint bug JDK-8202385.
>>>
>>> I'll add as sentence indicating that the checks are for 
>>> "Serializable but not Externalizable" classes.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>>
>


From roger.riggs at oracle.com  Fri Aug 10 17:47:07 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 10 Aug 2018 13:47:07 -0400
Subject: [12] RFR 8200151: Add 8 JNDI tests to
 com/sun/jndi/dns/ConfigTests/
In-Reply-To: <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com>
References: <9FD6703A-49E8-41D8-B527-8D0D09726EB0@oracle.com>
 <c34ea8df-8feb-e52a-ded9-5f8ab0dae7b2@oracle.com>
 <8961A4DD-5119-46BD-B2B4-A3162302CAF7@oracle.com>
 <7fc8c142-1047-84b3-a009-d06e39dc0e92@oracle.com>
 <A0464C7B-5214-4AB0-9446-9C2B96FD0CD9@oracle.com>
 <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com>
Message-ID: <3afd41a3-ef1c-7092-6d37-66bfc23081a7@oracle.com>

Hi Chris,

There seems to be a lot of repetition in tests that could be combined.
For example, the RecursiveDefault, RecursiveTrue, and RecursiveFalse 
tests should be a
single test that is invoked 3 times, (multiple @run lines) with an 
argument to say which case to test.
There would be fewer files and less code to maintain.

The same goes for AuthDefault, AuthTrue and AuthFalse.

Why is PortUnreachable added to the ProblemList and also included in the 
Change set.
It would cleaner to treat it separately if it can't be fixed as part of 
adding these new tests.

Consider using java.time.Instant and Duration for the Timeout test;
it will print nicer and has some handy methods.

Regards, Roger


On 8/10/18 5:15 AM, Chris Yin wrote:
> Minor revision to address testbase javadoc, initContext() expansion, @Override line and imports place, new webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8200151/webrev.02/
>
> Regards,
> Chris
>
>> On 30 Jul 2018, at 5:08 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>
>> Thank you, Vyom
>>
>> Regards,
>> Chris
>>
>>> On 30 Jul 2018, at 5:06 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>
>>> Hi Chris,
>>>
>>> Latest code looks good to me.
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>> On Friday 27 July 2018 01:12 PM, Chris Yin wrote:
>>>> Hi, Vyom
>>>>
>>>> Thank a lot for your review and comments, inline and update new webrev as below, thanks
>>>>
>>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.01/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.01/>
>>>>
>>>>
>>>>> On 26 Jul 2018, at 5:27 PM, vyom tewari <vyom.tewari at oracle.com <mailto:vyom.tewari at oracle.com>> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Thanks for writing the tests overall code looks good to me, below are few minor comments.
>>>>>
>>>>> 1`-> Fix tag order, my Netbeans always complains :) .
>>>> Fixed, thanks
>>>>
>>>>> 2->  you make AuthRecursiveBase class as public but i can not see it is being used outside,  i will suggest you to give the default access if possible.
>>>> Sure, changed it to default access now
>>>>
>>>>> 3-> AuthTrue.java, change the message as follows
>>>>>
>>>>> "Got exception as expected : " -> "Got expected exception: ?;
>>>> Fixed
>>>>
>>>>>
>>>>> 4-> PortUnreachable.java , any specific reason for 1000ms or you just choose random value ? Please don't hard-code this specific value  create a  constant and use it . If possible put some comment why we choose 1 second, this will help in debugging if this test fails intermittently in future.
>>>> Sure, I created a constant ?THRESHOLD' for it, 1000ms will be used as a threshold value for this test, normally the request should fail very quick (in a few ms), but consider to different platform and test machine performance, we used an acceptable threshold here, some comments added to it in the code too, thanks
>>>>
>>>>> 5-> Timeout.java, do you really need to set the env using "DNSTestUtils.initEnv" ?
>>>>>
>>>>> I see, this test is not using the DNSServer and other environments variables which were set by "DNSTestUtils.initEnv()" or i am missing something.
>>>> Actually, it?s indeed not necessary, just set very few default value such as ?Context.INITIAL_CONTEXT_FACTORY? in the test code should be fine, but I may still want to keep the test consistency, then we could have better maintainability for those tests. Sorry, I forgot to refactor this test with testbase (actually, its not necessary too, but guess the consistent style and shared base/methods will make the test easy to read and maintain, refactored this test and PortUnreachable.java now)
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>> Thanks,
>>>>> Vyom
>>>>>
>>>>> On Wednesday 25 July 2018 02:41 PM, Chris Yin wrote:
>>>>>> Please review the changes to add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ in OpenJDK, due to known issue 7164518, PortUnreachable.java will be problem list for 'macosx-all', thanks
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151> <https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151>>
>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/> <http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/>>
>>>>>>
>>>>>> Regards,
>>>>>> Chris


From roger.riggs at oracle.com  Fri Aug 10 18:02:04 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 10 Aug 2018 14:02:04 -0400
Subject: Initial JDK 11 RFR of JDK-8202385: Annotation to mark
 serial-related fields and methods
In-Reply-To: <970afff0-ac0a-6f62-78c9-06595834a6ea@oracle.com>
References: <0fc9f7bf-120a-ff7d-1119-acfe233a00c2@oracle.com>
 <234afda3-7ba2-88d7-22d9-1c08b4667e48@Oracle.com>
 <d4078a24-653c-e25d-89f4-d9526519f807@oracle.com>
 <7905537a-659b-6dfe-bb8c-4c8aefda2b02@oracle.com>
 <788c428b-f4da-ad0d-6bc1-c5a8092d1c51@Oracle.com>
 <970afff0-ac0a-6f62-78c9-06595834a6ea@oracle.com>
Message-ID: <56013032-6431-1f35-6711-dd1b94d9bffb@oracle.com>

Hi Joe,

serialVersionUID is used to confirm the identity of a class so it is 
applicable to classes
implementing Externalizable as well as Serializable. (And also 
serialization of a class itself).

Thanks, Roger

On 8/10/18 1:39 PM, joe darcy wrote:
> Hi Roger,
>
> Returning to this topic, I'll add a clause in the spec for 
> serialPersistentFields and Externalizable and corresponding code in 
> the checker. Should there be a similar check for serialVersionUID in 
> an Externalizable class? It wasn't clear to me from reading the specs 
> and there are cases in the JDK of classes implementing Externalizable 
> and having serialVersionUID fields defined.
>
> Thanks,
>
> -Joe
>
>
> On 5/10/2018 2:26 PM, Roger Riggs wrote:
>> Hi Joe,
>>
>> The words are fine.
>>
>> The field serialPersistentFields is also not used with @Externalizable.
>>
>> I would guess the lint checker would flag those methods and field for 
>> warnings for Externalizable classes
>> since they might mislead to think they were used.
>>
>> Roger
>>
>>
>> On 5/10/2018 5:03 PM, joe darcy wrote:
>>> PS After additional reading, I propose to add the follow clause to 
>>> where using the annotation is not appropriate:
>>>
>>> ?* <li>the {@code writeObject}, {@code readObject}, and {@code
>>> ?* readObjectNoData} methods in a class that is {@code
>>> ?* Externalizable}. While the {@code Externalizable} interface extends
>>> ?* {@code Serializable}, those three methods are not used for
>>> ?* externalizable classes.
>>>
>>> How does that sound?
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>>> On 5/10/2018 1:22 PM, joe darcy wrote:
>>>> Hi Roger,
>>>>
>>>> Right; there are a few other distinguished methods defined for 
>>>> externalization, but they are defined on the as methods on the 
>>>> Externalizable interface as far as I can tell. The existence of 
>>>> externalization is mentioned in the javac lint bug JDK-8202385.
>>>>
>>>> I'll add as sentence indicating that the checks are for 
>>>> "Serializable but not Externalizable" classes.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>>
>>>
>>
>


From joe.darcy at oracle.com  Fri Aug 10 18:18:50 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 10 Aug 2018 11:18:50 -0700
Subject: Initial JDK 11 RFR of JDK-8202385: Annotation to mark
 serial-related fields and methods
In-Reply-To: <56013032-6431-1f35-6711-dd1b94d9bffb@oracle.com>
References: <0fc9f7bf-120a-ff7d-1119-acfe233a00c2@oracle.com>
 <234afda3-7ba2-88d7-22d9-1c08b4667e48@Oracle.com>
 <d4078a24-653c-e25d-89f4-d9526519f807@oracle.com>
 <7905537a-659b-6dfe-bb8c-4c8aefda2b02@oracle.com>
 <788c428b-f4da-ad0d-6bc1-c5a8092d1c51@Oracle.com>
 <970afff0-ac0a-6f62-78c9-06595834a6ea@oracle.com>
 <56013032-6431-1f35-6711-dd1b94d9bffb@oracle.com>
Message-ID: <3f55cf96-ccce-d95c-12b5-a803071c6fdd@oracle.com>

Hi Roger,

Thanks for the explanation; I'll adjust the proposed java.io.Serial spec 
and serialization-related check accordingly.

Cheers,

-Joe


On 8/10/2018 11:02 AM, Roger Riggs wrote:
> Hi Joe,
>
> serialVersionUID is used to confirm the identity of a class so it is 
> applicable to classes
> implementing Externalizable as well as Serializable. (And also 
> serialization of a class itself).
>
> Thanks, Roger
>
> On 8/10/18 1:39 PM, joe darcy wrote:
>> Hi Roger,
>>
>> Returning to this topic, I'll add a clause in the spec for 
>> serialPersistentFields and Externalizable and corresponding code in 
>> the checker. Should there be a similar check for serialVersionUID in 
>> an Externalizable class? It wasn't clear to me from reading the specs 
>> and there are cases in the JDK of classes implementing Externalizable 
>> and having serialVersionUID fields defined.
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> On 5/10/2018 2:26 PM, Roger Riggs wrote:
>>> Hi Joe,
>>>
>>> The words are fine.
>>>
>>> The field serialPersistentFields is also not used with @Externalizable.
>>>
>>> I would guess the lint checker would flag those methods and field 
>>> for warnings for Externalizable classes
>>> since they might mislead to think they were used.
>>>
>>> Roger
>>>
>>>
>>> On 5/10/2018 5:03 PM, joe darcy wrote:
>>>> PS After additional reading, I propose to add the follow clause to 
>>>> where using the annotation is not appropriate:
>>>>
>>>> ?* <li>the {@code writeObject}, {@code readObject}, and {@code
>>>> ?* readObjectNoData} methods in a class that is {@code
>>>> ?* Externalizable}. While the {@code Externalizable} interface extends
>>>> ?* {@code Serializable}, those three methods are not used for
>>>> ?* externalizable classes.
>>>>
>>>> How does that sound?
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 5/10/2018 1:22 PM, joe darcy wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Right; there are a few other distinguished methods defined for 
>>>>> externalization, but they are defined on the as methods on the 
>>>>> Externalizable interface as far as I can tell. The existence of 
>>>>> externalization is mentioned in the javac lint bug JDK-8202385.
>>>>>
>>>>> I'll add as sentence indicating that the checks are for 
>>>>> "Serializable but not Externalizable" classes.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>>
>>>>
>>>
>>
>


From martinrb at google.com  Fri Aug 10 19:57:05 2018
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 10 Aug 2018 12:57:05 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
Message-ID: <CA+kOe092Su=ghCsXy7mov_hntNL3UC+rnpk+3Ly2Z9eTx6nXWA@mail.gmail.com>

retargeted bug to java.util:i18n, the right mailing list seems to be
i18n-dev.

On Fri, Aug 10, 2018 at 8:42 AM, Adam Farley8 <adam.farley at uk.ibm.com>
wrote:

> Hi All,
>
> This bug could be fixed by comparing the Class Loader with a blank
> static volatile Object (defined outside the method scope) at the
> end of the getBundleImpl class.
>
> E.g.
>
> -----------------------------------------
> +1322
>     /**
>      * volatile reference object to guard the ClassLoader object
>      * being garbage collected before getBundleImpl() method completes
>      * the caching and retrieving of requested Resourcebundle object
>      */
>     private static volatile Object vo = new Object();
>
>
> +1400
> //Should never be true. Using the loader here prevents it being GC'd.
>             if (loader == vo) throw new Error("Unexpected error.");
> -----------------------------------------
>
> Will upload a webrev after debate.
>
> - Adam
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

From igor.ignatyev at oracle.com  Fri Aug 10 20:22:50 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 10 Aug 2018 13:22:50 -0700
Subject: RFR(XXS) : 8209382 : [error-prone] HashtableContains in
 sun/rmi/server/ActivationGroupImpl.java
Message-ID: <12AE4B22-1100-4B44-B53A-4AC94A33F9FF@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
> 2 lines changed: 0 ins; 0 del; 2 mod; 

Hi all,

could you please review this one-line patch for the error reported by error-prone?

JBS: https://bugs.openjdk.java.net/browse/JDK-8209382
webrev: http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html

Thanks,
-- Igor

From mearvk at outlook.com  Fri Aug 10 20:41:14 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 10 Aug 2018 20:41:14 +0000
Subject: JVMTI lib location
Message-ID: <SN6PR07MB5022433D6DED564CA7C5FC81DA240@SN6PR07MB5022.namprd07.prod.outlook.com>

Trying to write a quick agent for the JVM.  The jvmti.h file is found quickly but I do not know what to link it with.  Can you guys help?

Thanks.

Max r.

From igor.ignatyev at oracle.com  Fri Aug 10 20:44:15 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 10 Aug 2018 13:44:15 -0700
Subject: RFR(XXS) : 8209386 : [error-prone] StreamResourceLeak in
 jdk.internal.ed module
Message-ID: <3AB5CED9-A9BE-4686-AFAE-05A6E5D10CE6@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
> 4 lines changed: 1 ins; 0 del; 3 mod;

Hi all,

could you please review this small fix for the error detected in jdk.internal.ed by error-prone?

webrev: http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8209386

Thanks,
-- Igor 

From roger.riggs at oracle.com  Fri Aug 10 20:49:00 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 10 Aug 2018 16:49:00 -0400
Subject: RFR(XXS) : 8209382 : [error-prone] HashtableContains in
 sun/rmi/server/ActivationGroupImpl.java
In-Reply-To: <12AE4B22-1100-4B44-B53A-4AC94A33F9FF@oracle.com>
References: <12AE4B22-1100-4B44-B53A-4AC94A33F9FF@oracle.com>
Message-ID: <133be988-3a7f-906c-0f23-47b9e84ff5d9@oracle.com>

Hi Igor,

Looks fine

Roger

On 8/10/18 4:22 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
>> 2 lines changed: 0 ins; 0 del; 2 mod;
> Hi all,
>
> could you please review this one-line patch for the error reported by error-prone?
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209382
> webrev: http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
>
> Thanks,
> -- Igor


From ivan.gerasimov at oracle.com  Sat Aug 11 02:03:18 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 10 Aug 2018 19:03:18 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
Message-ID: <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>

Thanks Martin!


On 8/9/18 5:42 PM, Martin Buchholz wrote:
>
>
> On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     I did not use the intrinsified variants of numberOfLeadingZeros in
>     the benchmark.
>
>
> Oops! Should have looked more closely!
> Did you know about
> http://www.hackersdelight.org/hdcodetxt/ntz.c.txt

Ah, right, ntz1() is even better because it has less branches.  How 
could I miss that?

Here's the updated webrev and benchmarks:

http://cr.openjdk.java.net/~igerasim/8209171/01/webrev/
http://cr.openjdk.java.net/~igerasim/8209171/01/bench/int/MyBenchmark.java
http://cr.openjdk.java.net/~igerasim/8209171/01/bench/long/MyBenchmark.java

-- 
With kind regards,
Ivan Gerasimov


From ecki at zusammenkunft.net  Sat Aug 11 19:31:50 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 11 Aug 2018 21:31:50 +0200
Subject: (XS) java.logging Level.java minor cleanups
Message-ID: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>

Hello,

while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but not in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level) in the master queries a unused class name (pn) and it can use the method reference instead of Lambda. See patch below.

There seems to be also a opportunity to use computeIfAbsent in a unrelated method add(Level), not sure if this is wanted, what do you think?


index dbc27124d33..401c6dc73e0 100644
--- a/src/java.logging/share/classes/java/util/logging/Level.java
+++ b/src/java.logging/share/classes/java/util/logging/Level.java
@@ -610,10 +610,7 @@ public class Level implements java.io.Serializable {
         }

         private static void registerWithClassLoader(Level customLevel) {
-            PrivilegedAction<ClassLoader> pa =
-                  () -> customLevel.getClass().getClassLoader();
-            PrivilegedAction<String> pn =  customLevel.getClass()::getName;
-            final String name = AccessController.doPrivileged(pn);
+            PrivilegedAction<ClassLoader> pa = customLevel.getClass()::getClassLoader;
             final ClassLoader cl = AccessController.doPrivileged(pa);
             CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
                 .add(customLevel);
@@ -624,19 +621,10 @@ public class Level implements java.io.Serializable {
             // the mirroredLevel object is always added to the list
             // before the custom Level instance
             KnownLevel o = new KnownLevel(l);
-            List<KnownLevel> list = nameToLevels.get(l.name);
-            if (list == null) {
-                list = new ArrayList<>();
-                nameToLevels.put(l.name, list);
-            }
-            list.add(o);
-
-            list = intToLevels.get(l.value);
-            if (list == null) {
-                list = new ArrayList<>();
-                intToLevels.put(l.value, list);
-            }
-            list.add(o);
+            nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
+                .add(o);
+            intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
+                .add(o);

             // keep the custom level reachable from its class loader
             // This will ensure that custom level values are not GC'ed


I am happy if anyone can sponsor this change.

BTW: I get a synthetic Accessor warning on l.name/value, is this what nestmates will resolve ? is it worth adjusting the modifiers for those fields anyway?

Gruss
Bernd
-- 
http://bernd.eckenfels.net


From mearvk at outlook.com  Sat Aug 11 20:04:09 2018
From: mearvk at outlook.com (mr rupplin)
Date: Sat, 11 Aug 2018 20:04:09 +0000
Subject: C files and their Mapping(s)
Message-ID: <SN6PR07MB50223D9F9E1190C9C692AC3ADA3B0@SN6PR07MB5022.namprd07.prod.outlook.com>

Hello.

Thanks for taking time.  We had a quick question about the Java to C mappings in the JDK.  For instance the System.java has a corresponding System.c and even a System.o.

We find these without too much problem.  However many of the "core" packages (corba, nashorn, jaxp, jaxws) do not have a corresponding C source folder.

If we were to make changes to System.java we would, for example, also make changes to System.c.  It is quickly clear then that we would need a mechanism for altering the remaining java classes.  Since these do not have a C file what do we then alter?  How would we rewrite a method, add one, etc.?

-- -- -- --

Thank you,

Max

From ecki at zusammenkunft.net  Sat Aug 11 20:52:51 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 11 Aug 2018 22:52:51 +0200
Subject: C files and their Mapping(s)
In-Reply-To: <SN6PR07MB50223D9F9E1190C9C692AC3ADA3B0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50223D9F9E1190C9C692AC3ADA3B0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <5b6f4ca3.1c69fb81.19330.97d1@mx.google.com>

If a Java class from does not use native Methods then no corresponding native implementation is existing/needed (with the Special exception of intrinsics). Most of the JCL is purely Java.

What is it you want to modify?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: mr rupplin
Gesendet: Samstag, 11. August 2018 22:17
An: core-libs-dev at openjdk.java.net
Betreff: C files and their Mapping(s)

Hello.

Thanks for taking time.  We had a quick question about the Java to C mappings in the JDK.  For instance the System.java has a corresponding System.c and even a System.o.

We find these without too much problem.  However many of the "core" packages (corba, nashorn, jaxp, jaxws) do not have a corresponding C source folder.

If we were to make changes to System.java we would, for example, also make changes to System.c.  It is quickly clear then that we would need a mechanism for altering the remaining java classes.  Since these do not have a C file what do we then alter?  How would we rewrite a method, add one, etc.?

-- -- -- --

Thank you,

Max


From martinrb at google.com  Sun Aug 12 00:54:50 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 11 Aug 2018 17:54:50 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
Message-ID: <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>

Hi Ivan,

Oh the allure of bit-twiddling!

I'm skeptical that ntz should ever delegate to nlz, and not only because of
the overhead of a wrapper, but because small numbers are more common, and
we can take that into account when implementing ntz.  At least add "1" to
the set of numbers to benchmark.  Here's my own entry in this race:

    static int ntz(int i) {
        if (i == 0) return 32;
        int n = 0;
        if ((i << 16)  == 0) { n += 16; i >>>= 16; }
        if ((i & 0xFF) == 0) { n +=  8; i >>>=  8; }
        if ((i & 0xF)  == 0) { n +=  4; i >>>=  4; }
        if ((i & 0x3)  == 0) { n +=  2; i >>>=  2; }
        return n + (~i & 1);
    }

Whatever happens, we ought to check in the microbenchmarks somewhere.  It
looks like the new jmh-jdk-microbenchmarks is the place.
I also suspect that tests for these methods could be improved (but there
are existing hotspot tests).

nlz seems harder than ntz in the sense that for nlz "small ints" and random
bits may have different optimal implementations.


On Fri, Aug 10, 2018 at 7:03 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Thanks Martin!
>
> On 8/9/18 5:42 PM, Martin Buchholz wrote:
>
>
>
> On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
>
>> I did not use the intrinsified variants of numberOfLeadingZeros in the
>> benchmark.
>>
>
> Oops! Should have looked more closely!
>
> Did you know about
> http://www.hackersdelight.org/hdcodetxt/ntz.c.txt
>
>
> Ah, right, ntz1() is even better because it has less branches.  How could
> I miss that?
>
> Here's the updated webrev and benchmarks:
>
> http://cr.openjdk.java.net/~igerasim/8209171/01/webrev/
> http://cr.openjdk.java.net/~igerasim/8209171/01/bench/int/MyBenchmark.java
> http://cr.openjdk.java.net/~igerasim/8209171/01/bench/
> long/MyBenchmark.java
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From ivan.gerasimov at oracle.com  Sun Aug 12 14:22:09 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 12 Aug 2018 07:22:09 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
Message-ID: <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>

Hi Martin!


On 8/11/18 5:54 PM, Martin Buchholz wrote:
> Hi Ivan,
>
> Oh the allure of bit-twiddling!
>
Yes :)

> I'm skeptical that ntz should ever delegate to nlz, and not only 
> because of the overhead of a wrapper, but because small numbers are 
> more common, and we can take that into account when implementing ntz.
I was under impression that the more frequently a function is called the 
faster it gets compiled, so all the callers of this function will benefit.
For example, if numberOfTrailingZeros is reduced to numberOfLeadingZeros 
then when the later is compiled while the former is still not, it will 
still be running faster than the variant with independent implementations.

>   At least add "1" to the set of numbers to benchmark.
In the last proposed patch, all odd numbers will be processed via a fast 
path (because for any odd i, ~i & (i - 1) == 0).
So, I added 1, 16 and 42 -- small numbers with different number of 
trailing zeros.

Here's the updated benchmark:
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
(I only executed four implementations to keep the picture clear.)

>   Here's my own entry in this race:
>
>     static int ntz(int i) {
>         if (i == 0) return 32;
>         int n = 0;
>         if ((i << 16)  == 0) { n += 16; i >>>= 16; }
>         if ((i & 0xFF) == 0) { n +=  8; i >>>=  8; }
>         if ((i & 0xF)  == 0) { n +=  4; i >>>=  4; }
>         if ((i & 0x3)  == 0) { n +=  2; i >>>=  2; }
>         return n + (~i & 1);
>     }
>
Interesting!
You might also avoid inversion at the end, if n is initialized with 1, 
and then the last line may be written as return n - (i & 1).

Still this variant appears to be slower in most tried cases.
Here's the graph of the latest benchmark:
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-client.png
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-server.png

The variant from the test01 is the fastest in most cases, but I would 
prefer to proceed with the variant from test05:
It's only slightly slower than 01, but contains less bytecode and helps 
to warm up numberOfLeadingZeros().

> Whatever happens, we ought to check in the microbenchmarks somewhere.  
> It looks like the new jmh-jdk-microbenchmarks is the place.
> I also suspect that tests for these methods could be improved (but 
> there are existing hotspot tests).
>
To make sure the new code is correct I ran an exhaustive loop from 
Integer.MIN_VALUE to MAX_VALUE inclusive and checked all the tested 
variants of implementation.

> nlz seems harder than ntz in the sense that for nlz "small ints" and 
> random bits may have different optimal implementations.
>
>
> On Fri, Aug 10, 2018 at 7:03 PM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Thanks Martin!
>
>
>     On 8/9/18 5:42 PM, Martin Buchholz wrote:
>>
>>
>>     On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov
>>     <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>>
>>         I did not use the intrinsified variants of
>>         numberOfLeadingZeros in the benchmark.
>>
>>
>>     Oops! Should have looked more closely!
>>     Did you know about
>>     http://www.hackersdelight.org/hdcodetxt/ntz.c.txt
>>     <http://www.hackersdelight.org/hdcodetxt/ntz.c.txt>
>
>     Ah, right, ntz1() is even better because it has less branches. 
>     How could I miss that?
>
>     Here's the updated webrev and benchmarks:
>
>     http://cr.openjdk.java.net/~igerasim/8209171/01/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/webrev/>
>     http://cr.openjdk.java.net/~igerasim/8209171/01/bench/int/MyBenchmark.java
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/bench/int/MyBenchmark.java>
>     http://cr.openjdk.java.net/~igerasim/8209171/01/bench/long/MyBenchmark.java
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/bench/long/MyBenchmark.java>
>
>     -- 
>     With kind regards,
>     Ivan Gerasimov
>
>

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Sun Aug 12 17:57:10 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 12 Aug 2018 10:57:10 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
Message-ID: <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>

If delegating to nlz is the winner so far, we should be able to do at least
as well by inlining nlz into ntz and then looking for more optimizations.
Following this strategy leads naturally to

    static int ntz_inlineNlz2(int i) {
        i &= -i;
        if (i <= 0) return 32 - (i >>> 31);
        int n = 0;
        if (i >= 1 << 16) { n += 16; i >>>= 16; }
        if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
        if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
        if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
        return n + (i >>> 1);
    }

which should save a branch and so should be a benchmark winner.

A reason why delegating to nlz may have beat my previous attempt is because
direct comparison with a constant is an operation the hardware tries hard
to optimize, e.g. branch predict.

Most of the comparisons should be false in practice because "most ints are
small".

I also see that our nlz implementation favors small integers, which helps
with ntz.

It's possible that benchmarking may cause branches to be very highly
predictable.  It should be more real-world for each benchmark method to see
a variety of inputs, perhaps in an array.


On Sun, Aug 12, 2018 at 7:22 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hi Martin!
>
> On 8/11/18 5:54 PM, Martin Buchholz wrote:
>
> Hi Ivan,
>
> Oh the allure of bit-twiddling!
>
> Yes :)
>
> I'm skeptical that ntz should ever delegate to nlz, and not only because
> of the overhead of a wrapper, but because small numbers are more common,
> and we can take that into account when implementing ntz.
>
> I was under impression that the more frequently a function is called the
> faster it gets compiled, so all the callers of this function will benefit.
> For example, if numberOfTrailingZeros is reduced to numberOfLeadingZeros
> then when the later is compiled while the former is still not, it will
> still be running faster than the variant with independent implementations.
>
>   At least add "1" to the set of numbers to benchmark.
>
> In the last proposed patch, all odd numbers will be processed via a fast
> path (because for any odd i, ~i & (i - 1) == 0).
> So, I added 1, 16 and 42 -- small numbers with different number of
> trailing zeros.
>
> Here's the updated benchmark:
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
> (I only executed four implementations to keep the picture clear.)
>
>   Here's my own entry in this race:
>
>     static int ntz(int i) {
>         if (i == 0) return 32;
>         int n = 0;
>         if ((i << 16)  == 0) { n += 16; i >>>= 16; }
>         if ((i & 0xFF) == 0) { n +=  8; i >>>=  8; }
>         if ((i & 0xF)  == 0) { n +=  4; i >>>=  4; }
>         if ((i & 0x3)  == 0) { n +=  2; i >>>=  2; }
>         return n + (~i & 1);
>     }
>
> Interesting!
> You might also avoid inversion at the end, if n is initialized with 1, and
> then the last line may be written as return n - (i & 1).
>
> Still this variant appears to be slower in most tried cases.
> Here's the graph of the latest benchmark:
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/
> bench-int-02-client.png
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/
> bench-int-02-server.png
>
> The variant from the test01 is the fastest in most cases, but I would
> prefer to proceed with the variant from test05:
> It's only slightly slower than 01, but contains less bytecode and helps to
> warm up numberOfLeadingZeros().
>
> Whatever happens, we ought to check in the microbenchmarks somewhere.  It
> looks like the new jmh-jdk-microbenchmarks is the place.
> I also suspect that tests for these methods could be improved (but there
> are existing hotspot tests).
>
> To make sure the new code is correct I ran an exhaustive loop from
> Integer.MIN_VALUE to MAX_VALUE inclusive and checked all the tested
> variants of implementation.
>
> nlz seems harder than ntz in the sense that for nlz "small ints" and
> random bits may have different optimal implementations.
>
>
> On Fri, Aug 10, 2018 at 7:03 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com
> > wrote:
>
>> Thanks Martin!
>>
>> On 8/9/18 5:42 PM, Martin Buchholz wrote:
>>
>>
>>
>> On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com
>> > wrote:
>>
>>> I did not use the intrinsified variants of numberOfLeadingZeros in the
>>> benchmark.
>>>
>>
>> Oops! Should have looked more closely!
>>
>> Did you know about
>> http://www.hackersdelight.org/hdcodetxt/ntz.c.txt
>>
>>
>> Ah, right, ntz1() is even better because it has less branches.  How could
>> I miss that?
>>
>> Here's the updated webrev and benchmarks:
>>
>> http://cr.openjdk.java.net/~igerasim/8209171/01/webrev/
>> http://cr.openjdk.java.net/~igerasim/8209171/01/bench/int/My
>> Benchmark.java
>> http://cr.openjdk.java.net/~igerasim/8209171/01/bench/long/
>> MyBenchmark.java
>>
>> --
>> With kind regards,
>> Ivan Gerasimov
>>
>>
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From martinrb at google.com  Sun Aug 12 22:45:21 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 12 Aug 2018 15:45:21 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
Message-ID: <CA+kOe08cVQLsBXnNJ1NVmfx3m4EHMSkuGMvCDx6Dk7wML3LEGA@mail.gmail.com>

Here's an example of a microbenchmark that uses multiple random inputs
simulating various typical populations:

https://github.com/google/caliper/blob/master/caliper-examples/src/main/java/examples/Utf8Benchmark.java

From david.holmes at oracle.com  Sun Aug 12 23:07:56 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 13 Aug 2018 09:07:56 +1000
Subject: JVMTI lib location
In-Reply-To: <SN6PR07MB5022433D6DED564CA7C5FC81DA240@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022433D6DED564CA7C5FC81DA240@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <85396ac8-5895-9993-c6e0-c65461c277a7@oracle.com>

Hi Max,

On 11/08/2018 6:41 AM, mr rupplin wrote:
> Trying to write a quick agent for the JVM.  The jvmti.h file is found quickly but I do not know what to link it with.  Can you guys help?

JVM TI is a serviceability-dev topic, though that's really about 
developing JVM TI not using it. There are numerous tutorials/blog pages 
on using JVM TI e.g. [1]. IIUC the JVM TI agent library is dynamically 
loaded into the JVM and thus dynamically linked with the JVM TI runtime 
- so you don't have to link your library with anything to access JVM TI.

David

[1] http://www.oracle.com/technetwork/articles/javase/index-140680.html

> Thanks.
> 
> Max r.
> 

From mearvk at outlook.com  Mon Aug 13 01:49:19 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 13 Aug 2018 01:49:19 +0000
Subject: Command 'make jdk' no longer runs ; request a quick look
Message-ID: <SN6PR07MB5022B9B0C67484E3A548A589DA390@SN6PR07MB5022.namprd07.prod.outlook.com>

Building target 'jdk' in configuration 'linux-x86_64-normal-server-release'
Creating ct.sym classes
Compiling 11 properties into resource bundles for java.logging
Compiling 2 files for BUILD_BREAKITERATOR_BASE
Compiling 2 files for BUILD_BREAKITERATOR_LD
Exception in thread "main" java.lang.AssertionError
        at com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
        at com.sun.tools.javac.comp.Modules.allModules(Modules.java:1193)
        at com.sun.tools.javac.comp.Modules.getObservableModule(Modules.java:1388)
        at com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:136)
        at com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:84)
        at build.tools.symbolgenerator.TransitiveDependencies.main(TransitiveDependencies.java:81)
make[3]: *** [/media/mearvk/SSD/OpenJDKs/SecureJVM/jdk9/build/linux-x86_64-normal-server-release/support/symbols/ct.sym-files/_the.symbols] Error 1
Gendata-jdk.compiler.gmk:64: recipe for target '/media/mearvk/SSD/OpenJDKs/SecureJVM/jdk9/build/linux-x86_64-normal-server-release/support/symbols/ct.sym-files/_the.symbols' failed
make[2]: *** [jdk.compiler-gendata] Error 2
make/Main.gmk:150: recipe for target 'jdk.compiler-gendata' failed

Here I'm stumped; we've not touched the make files and it still gives this dump.  We've stopped for a while and are picking back up shortly.  Can we clear this like right now?     -- thanks

From mearvk at outlook.com  Mon Aug 13 01:52:05 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 13 Aug 2018 01:52:05 +0000
Subject: JVMTI lib location
In-Reply-To: <85396ac8-5895-9993-c6e0-c65461c277a7@oracle.com>
References: <SN6PR07MB5022433D6DED564CA7C5FC81DA240@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <85396ac8-5895-9993-c6e0-c65461c277a7@oracle.com>
Message-ID: <SN6PR07MB502257B2E2B54E58E5596C97DA390@SN6PR07MB5022.namprd07.prod.outlook.com>

Where are the source codes for the following methods:


 err = (*jvmti)->GetMethodDeclaringClass(jvmti, frames[i].method, &declaring_class);

 err = (*jvmti)->GetClassSignature(jvmti, declaring_class, &declaringClassName, NULL);

Thanks,

Max
________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Sunday, August 12, 2018 7:07 PM
To: mr rupplin; core-libs-dev at openjdk.java.net; serviceability-dev
Subject: Re: JVMTI lib location

Hi Max,

On 11/08/2018 6:41 AM, mr rupplin wrote:
> Trying to write a quick agent for the JVM.  The jvmti.h file is found quickly but I do not know what to link it with.  Can you guys help?

JVM TI is a serviceability-dev topic, though that's really about
developing JVM TI not using it. There are numerous tutorials/blog pages
on using JVM TI e.g. [1]. IIUC the JVM TI agent library is dynamically
loaded into the JVM and thus dynamically linked with the JVM TI runtime
- so you don't have to link your library with anything to access JVM TI.

David

[1] http://www.oracle.com/technetwork/articles/javase/index-140680.html

> Thanks.
>
> Max r.
>

From mearvk at outlook.com  Mon Aug 13 02:11:08 2018
From: mearvk at outlook.com (mr rupplin)
Date: Mon, 13 Aug 2018 02:11:08 +0000
Subject: Makefile Suppress Deprecation Warnings
Message-ID: <SN6PR07MB5022C15C2A671882DFE779BBDA390@SN6PR07MB5022.namprd07.prod.outlook.com>

Where in the Makefile would we add this to silence to deprecated warnings from GCC compiler?

-Wno-deprecated

Who thought this would be fine?  To run this seem falty.  ok

From ioi.lam at oracle.com  Mon Aug 13 02:54:35 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 12 Aug 2018 19:54:35 -0700
Subject: Makefile Suppress Deprecation Warnings
In-Reply-To: <SN6PR07MB5022C15C2A671882DFE779BBDA390@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C15C2A671882DFE779BBDA390@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <0c363608-82a5-c98e-00cf-b3cac0e29503@oracle.com>

It would be helpful if you can provide information like:

+ Which version of the JDK repo are you using?

+ Which platform are you building?


The only case I found under the make/ directory is here in the latest repo:

http://hg.openjdk.java.net/jdk/jdk/file/b7eb9cc56277/make/autoconf/flags-cflags.m4#l553

but that seems to be for the clang compiler.

Older JDK sources look like this, which might apply to gcc on macos:

http://hg.openjdk.java.net/jdk/jdk10/file/7d286141598c/make/autoconf/flags.m4#l1110


- Ioi


On 8/12/18 7:11 PM, mr rupplin wrote:
> Where in the Makefile would we add this to silence to deprecated warnings from GCC compiler?
>
> -Wno-deprecated
>
> Who thought this would be fine?  To run this seem falty.  ok


From ioi.lam at oracle.com  Mon Aug 13 03:01:44 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 12 Aug 2018 20:01:44 -0700
Subject: Command 'make jdk' no longer runs ; request a quick look
In-Reply-To: <SN6PR07MB5022B9B0C67484E3A548A589DA390@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022B9B0C67484E3A548A589DA390@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <6479378a-a33a-98da-c2eb-60f20f72554f@oracle.com>

What kind of modifications have you made to get you to this state? Have 
you tried undoing your changes one by one to see what causes this to happen?

I have to be honest with you. With the vague (and rude) questions that 
you have been sending to these mailing lists, I doubt anyone is really 
able, or willing, to help you out.

If you want to participate in the open source community, you have to 
learn the etiquettes.

And please -- use a real name and tell us who you work for.

Thanks
- Ioi


On 8/12/18 6:49 PM, mr rupplin wrote:
> Building target 'jdk' in configuration 'linux-x86_64-normal-server-release'
> Creating ct.sym classes
> Compiling 11 properties into resource bundles for java.logging
> Compiling 2 files for BUILD_BREAKITERATOR_BASE
> Compiling 2 files for BUILD_BREAKITERATOR_LD
> Exception in thread "main" java.lang.AssertionError
>          at com.sun.tools.javac.util.Assert.error(Assert.java:155)
>          at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
>          at com.sun.tools.javac.comp.Modules.allModules(Modules.java:1193)
>          at com.sun.tools.javac.comp.Modules.getObservableModule(Modules.java:1388)
>          at com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:136)
>          at com.sun.tools.javac.model.JavacElements.getModuleElement(JavacElements.java:84)
>          at build.tools.symbolgenerator.TransitiveDependencies.main(TransitiveDependencies.java:81)
> make[3]: *** [/media/mearvk/SSD/OpenJDKs/SecureJVM/jdk9/build/linux-x86_64-normal-server-release/support/symbols/ct.sym-files/_the.symbols] Error 1
> Gendata-jdk.compiler.gmk:64: recipe for target '/media/mearvk/SSD/OpenJDKs/SecureJVM/jdk9/build/linux-x86_64-normal-server-release/support/symbols/ct.sym-files/_the.symbols' failed
> make[2]: *** [jdk.compiler-gendata] Error 2
> make/Main.gmk:150: recipe for target 'jdk.compiler-gendata' failed
>
> Here I'm stumped; we've not touched the make files and it still gives this dump.  We've stopped for a while and are picking back up shortly.  Can we clear this like right now?     -- thanks


From ivan.gerasimov at oracle.com  Mon Aug 13 06:30:25 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 12 Aug 2018 23:30:25 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
Message-ID: <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>

On 8/12/18 10:57 AM, Martin Buchholz wrote:
> If delegating to nlz is the winner so far, we should be able to do at 
> least as well by inlining nlz into ntz and then looking for more 
> optimizations.  Following this strategy leads naturally to
>
>     static int ntz_inlineNlz2(int i) {
>         i &= -i;
>         if (i <= 0) return 32 - (i >>> 31);
>         int n = 0;
>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>         if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
>         if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
>         if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
>         return n + (i >>> 1);
>     }
>
Right.  The variant numberOfLeadingZeros_01() from the benchmark is very 
close to this, though you've got better handling of (i <= 0) case, so I 
added it as numberOfLeadingZeros_01a() with a minor modification.

> which should save a branch and so should be a benchmark winner.
>
> A reason why delegating to nlz may have beat my previous attempt is 
> because direct comparison with a constant is an operation the hardware 
> tries hard to optimize, e.g. branch predict.
>
> Most of the comparisons should be false in practice because "most ints 
> are small".
>
> I also see that our nlz implementation favors small integers, which 
> helps with ntz.
>
> It's possible that benchmarking may cause branches to be very highly 
> predictable.  It should be more real-world for each benchmark method 
> to see a variety of inputs, perhaps in an array.
>
Okay.  Now I tried to combine calculating of several results in one 
iteration of benchmark to make it harder to predict branches :)
Surprisingly, this made the variant 05 (reducing to nlz) the leader, for 
which I don't have a good explanation, as it does strictly more 
calculations than 01 or 01a even after inlining.

Anyways, please find the updated benchmark here:
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/MyBenchmark.java

The graphs for -client and -server are here:
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/bench-int-03-client.png
http://cr.openjdk.java.net/~igerasim/8209171/03/bench/int/bench-int-03-server.png

It took almost an hour to generate the results, so they seem to be quite 
accurate.

So, I'm still inclined to prefer the variant 05 (which is to reduce ntz 
to nlz)  :)

With kind regards,
Ivan

>
> On Sun, Aug 12, 2018 at 7:22 AM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hi Martin!
>
>
>     On 8/11/18 5:54 PM, Martin Buchholz wrote:
>>     Hi Ivan,
>>
>>     Oh the allure of bit-twiddling!
>>
>     Yes :)
>
>>     I'm skeptical that ntz should ever delegate to nlz, and not only
>>     because of the overhead of a wrapper, but because small numbers
>>     are more common, and we can take that into account when
>>     implementing ntz.
>     I was under impression that the more frequently a function is
>     called the faster it gets compiled, so all the callers of this
>     function will benefit.
>     For example, if numberOfTrailingZeros is reduced to
>     numberOfLeadingZeros then when the later is compiled while the
>     former is still not, it will still be running faster than the
>     variant with independent implementations.
>
>>       At least add "1" to the set of numbers to benchmark.
>     In the last proposed patch, all odd numbers will be processed via
>     a fast path (because for any odd i, ~i & (i - 1) == 0).
>     So, I added 1, 16 and 42 -- small numbers with different number of
>     trailing zeros.
>
>     Here's the updated benchmark:
>     http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/02/bench/int/MyBenchmark.java>
>     (I only executed four implementations to keep the picture clear.)
>
>>       Here's my own entry in this race:
>>
>>         static int ntz(int i) {
>>             if (i == 0) return 32;
>>             int n = 0;
>>             if ((i << 16)  == 0) { n += 16; i >>>= 16; }
>>             if ((i & 0xFF) == 0) { n +=  8; i >>>=  8; }
>>             if ((i & 0xF)  == 0) { n +=  4; i >>>=  4; }
>>             if ((i & 0x3)  == 0) { n +=  2; i >>>=  2; }
>>             return n + (~i & 1);
>>         }
>>
>     Interesting!
>     You might also avoid inversion at the end, if n is initialized
>     with 1, and then the last line may be written as return n - (i & 1).
>
>     Still this variant appears to be slower in most tried cases.
>     Here's the graph of the latest benchmark:
>     http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-client.png
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/02/bench/int/bench-int-02-client.png>
>     http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-02-server.png
>     <http://cr.openjdk.java.net/%7Eigerasim/8209171/02/bench/int/bench-int-02-server.png>
>
>     The variant from the test01 is the fastest in most cases, but I
>     would prefer to proceed with the variant from test05:
>     It's only slightly slower than 01, but contains less bytecode and
>     helps to warm up numberOfLeadingZeros().
>
>>     Whatever happens, we ought to check in the microbenchmarks
>>     somewhere.  It looks like the new jmh-jdk-microbenchmarks is the
>>     place.
>>     I also suspect that tests for these methods could be improved
>>     (but there are existing hotspot tests).
>>
>     To make sure the new code is correct I ran an exhaustive loop from
>     Integer.MIN_VALUE to MAX_VALUE inclusive and checked all the
>     tested variants of implementation.
>
>>     nlz seems harder than ntz in the sense that for nlz "small ints"
>>     and random bits may have different optimal implementations.
>>
>>
>>     On Fri, Aug 10, 2018 at 7:03 PM, Ivan Gerasimov
>>     <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>>
>>         Thanks Martin!
>>
>>
>>         On 8/9/18 5:42 PM, Martin Buchholz wrote:
>>>
>>>
>>>         On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov
>>>         <ivan.gerasimov at oracle.com
>>>         <mailto:ivan.gerasimov at oracle.com>> wrote:
>>>
>>>             I did not use the intrinsified variants of
>>>             numberOfLeadingZeros in the benchmark.
>>>
>>>
>>>         Oops! Should have looked more closely!
>>>         Did you know about
>>>         http://www.hackersdelight.org/hdcodetxt/ntz.c.txt
>>>         <http://www.hackersdelight.org/hdcodetxt/ntz.c.txt>
>>
>>         Ah, right, ntz1() is even better because it has less
>>         branches.  How could I miss that?
>>
>>         Here's the updated webrev and benchmarks:
>>
>>         http://cr.openjdk.java.net/~igerasim/8209171/01/webrev/
>>         <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/webrev/>
>>         http://cr.openjdk.java.net/~igerasim/8209171/01/bench/int/MyBenchmark.java
>>         <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/bench/int/MyBenchmark.java>
>>         http://cr.openjdk.java.net/~igerasim/8209171/01/bench/long/MyBenchmark.java
>>         <http://cr.openjdk.java.net/%7Eigerasim/8209171/01/bench/long/MyBenchmark.java>
>>
>>         -- 
>>         With kind regards,
>>         Ivan Gerasimov
>>
>>
>
>     -- 
>     With kind regards,
>     Ivan Gerasimov
>
>

-- 
With kind regards,
Ivan Gerasimov


From felix.yang at oracle.com  Mon Aug 13 09:09:12 2018
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 13 Aug 2018 17:09:12 +0800
Subject: RFR8194230, jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java
 fails with NPE
In-Reply-To: <181961ff-573a-dbff-7ba9-59d5e3afb980@oracle.com>
References: <73b18b56-5266-4274-f05a-75fcb87eef44@oracle.com>
 <181961ff-573a-dbff-7ba9-59d5e3afb980@oracle.com>
Message-ID: <284d8529-423e-7d7a-af87-01016ded88e5@oracle.com>

Hi Alan,

 ??? please review the update patch, and reduced checking as suggested:

http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.01/

Thanks,
Felix
On 2018/8/6 18:23, Alan Bateman wrote:
> On 31/07/2018 07:16, Felix Yang wrote:
>> Hi all,
>>
>> ??? please review a patch to improve the checking on the settings. 
>> Originally it will throw NPE, if specified path is invalid.
>>
>> Bug:
>>
>> ??? https://bugs.openjdk.java.net/browse/JDK-8194230
>>
>> Webrev:
>>
>> ??? http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.00/
> Have you considered merging getJdk8Path and isJdk8 so that it simple 
> checks for the release file and rejects the value of JDK8_HOME when it 
> doesn't exist? I think that should reduce the number of checks and 
> keep it very simple.
>
> -Alan


From rachna.goel at oracle.com  Mon Aug 13 09:48:24 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 13 Aug 2018 15:18:24 +0530
Subject: [11] RFR: 8209047:"Illegal pattern character 'B'"
 IllegalArgumentException with Burmese locales
Message-ID: <334cc1c4-3b95-aee3-f7f6-60860aa61715@oracle.com>

Hi,

Kindly review the fix to JDK-8209047.

Bug: https://bugs.openjdk.java.net/browse/JDK-8209047
webrev: http://cr.openjdk.java.net/~rgoel/JDK-8209047/webrev.03/

It is a regression caused by JDK-8202537. Because of the 'B' character 
introduced in the CLDR time patterns "B HH:mm:ss", "B H:mm" (where B 
represents the 'day period') for "my" (Burmese) locale. Since, this 
character is not supported in java.text.SimpleDateFormat and in 
java.time.DateTimeFormatter, it is throwing IllegalArgumentException. 
Fix is to change time pattern to previous CLDR's version i.e 29, until 
'B' character is supported via JDK-8209175.

-- 
Thanks,
Rachna


From claes.redestad at oracle.com  Mon Aug 13 14:16:14 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Aug 2018 16:16:14 +0200
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <ff8865ec-7c41-1b13-cfd0-f1c713af910f@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
 <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
 <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
 <ff8865ec-7c41-1b13-cfd0-f1c713af910f@oracle.com>
Message-ID: <3633e7cf-9ffb-2f96-4311-65b3df888eb3@oracle.com>

Hi Jiangli,

On 2018-08-10 19:15, Jiangli Zhou wrote:
> Hi Claes,
>
> The updated Integer.java looks good. The test also looks good to me. 
> I'd suggest adding some checks in CheckIntegerCacheApp test for the 
> cached Integers using WhiteBox API, WhiteBox.isShared(object) to make 
> sure that they are archived. Checking all cached Integers is probably 
> too excessive and unnecessary. Select a few values within [-128, 127] 
> range would be good enough, I think.
>
> As archived java heap data mapping may fail in some cases at runtime, 
> and there is no need to continue the test execution when that happens 
> as it would not exercise any of the archived java objects. The 
> following can be done at the beginning of CheckIntegerCacheApp:
>
> ??????? WhiteBox wb = WhiteBox.getWhiteBox();
>
> ??????? if (!wb.areOpenArchiveHeapObjectsMapped()) {
> ??????????? return;
> ??????? }

thanks for reviewing!

I've added WhiteBox testing as suggested:

http://cr.openjdk.java.net/~redestad/8209120/open.03/

/Claes



From martinrb at google.com  Mon Aug 13 14:56:53 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Aug 2018 07:56:53 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
 <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
Message-ID: <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>

The number of plausible variants is astonishing!

---

Your use of -client and -server is outdated, which explains why you get the
same results for both (-client is ignored).

I'm not sure what's blessed by hotspot team, but for C1 I
use -XX:+TieredCompilation  -XX:TieredStopAtLevel=1 and for C2 I
use -XX:-TieredCompilation -server

---

Now I understand the advantage of using ~i & (i - 1): the subsequent zero
check is a short-circuit for all odd numbers, better than i & -i, which
explains your results - they depend on being able to short-circuit.

So just use a more faithful inlining of nlz without trying to improve on it.

    static int ntz_inlineNlz5(int i) {
        i = ~i & (i - 1);
        if (i <= 0)
            return (i == 0) ? 0 : 32;
        int n = 1;
        if (i >= 1 << 16) { n += 16; i >>>= 16; }
        if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
        if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
        if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
        return n + (i >>> 1);
    }

But it's hard to resist the urge to optimize out a branch:

    static int ntz_inlineNlz6(int i) {
        i = ~i & (i - 1);
        if (i <= 0) return i & 32;
        int n = 1;
        if (i >= 1 << 16) { n += 16; i >>>= 16; }
        if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
        if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
        if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
        return n + (i >>> 1);
    }

From matthias.baesken at sap.com  Mon Aug 13 15:18:27 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 13 Aug 2018 15:18:27 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
Message-ID: <4c6b969405364fc394459e8cd1789842@sap.com>


>As Chris and Alan mentioned, you should move the parsing of the property 
>to a more general location so it can be used by other code that uses 
>this property.

Hi Sean, Thanks for  the input  and comments .
Could we do the moving  of the  property parsing    do  in a followup CR, I would prefer this .

Best regards, Matthias


> -----Original Message-----
> From: Sean Mullan <sean.mullan at oracle.com>
> Sent: Freitag, 10. August 2018 17:39
> To: Baesken, Matthias <matthias.baesken at sap.com>; Chris Hegarty
> <chris.hegarty at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
> dev at openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> I need more time to finish my review but here are some initial comments:
> 
> - java.security
> 
> 1079 #  jarpath - enables more detailed information in the IOExceptions
> thrown
> 
> Use "jarPath" to be consistent with "hostInfo".
> 
> 1080 #            by java.util.jar.Attributes  and java.util.jar.Manifest
> 
> and java.util.jar.JarFile
> 
> - Manifest.java
> 
> 57     private String jarFilename = null;
> 
> Not necessary to set it to null, as that is the default.
> 
>    82     Manifest(InputStream is, String jarFilename) throws IOException {
>    83         this.jarFilename = jarFilename;
>    84         read(is);
>    85     }
> 
> Read from the InputStream and check for error conditions *before*
> setting jarFilename (switch lines 83 & 84). This is a general best
> practice but can also protect against finalizer attacks. See JSCG 7-3
> for more info:
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7
> 
> - Attributes.java
> 
> As Chris and Alan mentioned, you should move the parsing of the property
> to a more general location so it can be used by other code that uses
> this property.
> 
> --Sean
> 
> On 8/8/18 11:00 AM, Sean Mullan wrote:
> > Cross-posting to security-dev since this fix is security related and
> > should also be reviewed there.
> >
> > --Sean
> >
> > On 8/7/18 11:00 AM, Baesken, Matthias wrote:
> >> Ping ....? ??? , any reviews / comments ?
> >>
> >> Thanks , Matthias
> >>
> >>> -----Original Message-----
> >>> From: Baesken, Matthias
> >>> Sent: Dienstag, 31. Juli 2018 12:28
> >>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; Alan Bateman
> >>> <Alan.Bateman at oracle.com>
> >>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> >>> <goetz.lindenmaier at sap.com>; Langer, Christoph
> >>> <christoph.langer at sap.com>
> >>> Subject: RE: [RFR] 8205525 : Improve exception messages during
> manifest
> >>> parsing of jar archives
> >>>
> >>> Hello ,
> >>> looks like? the? generalization of? the `includeInExceptions`
> >>> security?? property
> >>> is now in jdk/jdk? after
> >>>
> >>> "8207846: Generalize the jdk.net.includeInExceptions security property"
> >>>
> >>> was added, great news? and thanks to Chris for driving this !
> >>>
> >>> I use this security property now as well , and updated the? change :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
> >>>
> >>> I updated the CSR as well :
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>>
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Chris Hegarty <chris.hegarty at oracle.com>
> >>>> Sent: Donnerstag, 19. Juli 2018 14:54
> >>>> To: Alan Bateman <Alan.Bateman at oracle.com>; Baesken, Matthias
> >>>> <matthias.baesken at sap.com>
> >>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> >>>> <goetz.lindenmaier at sap.com>
> >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during
> manifest
> >>>> parsing of jar archives
> >>>>
> >>>>
> >>>>> On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com>
> >>>> wrote:
> >>>>>
> >>>>> On 19/07/2018 09:07, Baesken, Matthias wrote:
> >>>>>> Hello, in the meantime I? prepared a CSR :
> >>>>>>
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>>>>>
> >>>>>>
> >>>>>>> jdk.includeInExceptions expands the scope. That might be okay but
> we
> >>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the
> >>>>>>> support to somewhere in jdk.internal so that it can be used by
> other
> >>>>>>> code in java.base.
> >>>>>> Is there some support code for? " jdk.net.includeInExceptions "
> >>>>>> or do
> >>>> you just? mean? the name of the property ?
> >>>>>>
> >>>>> Chris is right that it's a bit premature to submit a CSR while the
> >>>>> question
> >>> on
> >>>> whether to rename the existing security property is on the table. I
> >>>> have no
> >>>> objection to doing that.
> >>>>
> >>>> I filed the following issue to generalize the `includeInExceptions`
> >>>> security
> >>>> ? property:
> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8207846
> >>>>
> >>>> I would like to resolve 8207846 first, then 8205525 can propose to
> >>>> add the
> >>>> new argument value, `jarPath`.
> >>>>
> >>>> -Chris.

From naoto.sato at oracle.com  Mon Aug 13 15:28:31 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 13 Aug 2018 08:28:31 -0700
Subject: <i18n dev> [11] RFR: 8209047:"Illegal pattern character 'B'"
 IllegalArgumentException with Burmese locales
In-Reply-To: <334cc1c4-3b95-aee3-f7f6-60860aa61715@oracle.com>
References: <334cc1c4-3b95-aee3-f7f6-60860aa61715@oracle.com>
Message-ID: <bd17bdca-6860-41e5-1570-d6c8f52d654f@oracle.com>

Looks good.

Naoto

On 8/13/18 2:48 AM, Rachna Goel wrote:
> Hi,
> 
> Kindly review the fix to JDK-8209047.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209047
> webrev: http://cr.openjdk.java.net/~rgoel/JDK-8209047/webrev.03/
> 
> It is a regression caused by JDK-8202537. Because of the 'B' character 
> introduced in the CLDR time patterns "B HH:mm:ss", "B H:mm" (where B 
> represents the 'day period') for "my" (Burmese) locale. Since, this 
> character is not supported in java.text.SimpleDateFormat and in 
> java.time.DateTimeFormatter, it is throwing IllegalArgumentException. 
> Fix is to change time pattern to previous CLDR's version i.e 29, until 
> 'B' character is supported via JDK-8209175.
> 

From jiangli.zhou at oracle.com  Mon Aug 13 16:36:35 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 13 Aug 2018 09:36:35 -0700
Subject: RFR: 8209120: Archive the Integer.IntegerCache
In-Reply-To: <3633e7cf-9ffb-2f96-4311-65b3df888eb3@oracle.com>
References: <b68df18d-5632-0e12-af1f-3216549d50fd@oracle.com>
 <4b7d1626-170f-e398-d7a3-9005b08016bd@gmail.com>
 <d0d22069-d6c6-fedc-ad86-82b0ae5f65e7@gmail.com>
 <6a29effd-979f-0033-146b-d1d9fe0dfb72@oracle.com>
 <c6ea7a5d-8c22-dee5-920d-88c4fc3e2d9a@oracle.com>
 <BF707EFB-3B91-4A4C-A596-3193EDD927C8@oracle.com>
 <81657089-e5f3-ba64-e758-d36c500b8af1@oracle.com>
 <ff8865ec-7c41-1b13-cfd0-f1c713af910f@oracle.com>
 <3633e7cf-9ffb-2f96-4311-65b3df888eb3@oracle.com>
Message-ID: <4e768b9f-7ca8-00b1-19b3-ce5e1c3ca6e7@oracle.com>

Hi Claes,

Looks good!

Thanks,

Jiangli


On 8/13/18 7:16 AM, Claes Redestad wrote:
> Hi Jiangli,
>
> On 2018-08-10 19:15, Jiangli Zhou wrote:
>> Hi Claes,
>>
>> The updated Integer.java looks good. The test also looks good to me. 
>> I'd suggest adding some checks in CheckIntegerCacheApp test for the 
>> cached Integers using WhiteBox API, WhiteBox.isShared(object) to make 
>> sure that they are archived. Checking all cached Integers is probably 
>> too excessive and unnecessary. Select a few values within [-128, 127] 
>> range would be good enough, I think.
>>
>> As archived java heap data mapping may fail in some cases at runtime, 
>> and there is no need to continue the test execution when that happens 
>> as it would not exercise any of the archived java objects. The 
>> following can be done at the beginning of CheckIntegerCacheApp:
>>
>> ??????? WhiteBox wb = WhiteBox.getWhiteBox();
>>
>> ??????? if (!wb.areOpenArchiveHeapObjectsMapped()) {
>> ??????????? return;
>> ??????? }
>
> thanks for reviewing!
>
> I've added WhiteBox testing as suggested:
>
> http://cr.openjdk.java.net/~redestad/8209120/open.03/
>
> /Claes
>
>


From ivan.gerasimov at oracle.com  Mon Aug 13 17:10:26 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 13 Aug 2018 10:10:26 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
 <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
 <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>
Message-ID: <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>

Hi Martin!

Good point about the command line flags, thanks!

These variants are close to numberOfTrailingZeros_07 that I've already 
tested, though you did better by saving one arithmetic operation at the 
return line!

I'll rerun the benchmarks.

With kind regards,

Ivan


On 8/13/18 7:56 AM, Martin Buchholz wrote:
> The number of plausible variants is astonishing!
>
> ---
>
> Your use of -client and -server is outdated, which explains why you 
> get the same results for both (-client is ignored).
>
> I'm not sure what's blessed by hotspot team, but for C1 I 
> use -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and for C2 I 
> use -XX:-TieredCompilation -server
>
> ---
>
> Now I understand the advantage of using ~i & (i - 1): the subsequent 
> zero check is a short-circuit for all odd numbers, better than i & -i, 
> which explains your results - they depend on being able to short-circuit.
>
> So just use a more faithful inlining of nlz without trying to improve 
> on it.
>
>     static int ntz_inlineNlz5(int i) {
>         i = ~i & (i - 1);
>         if (i <= 0)
>             return (i == 0) ? 0 : 32;
>         int n = 1;
>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>         if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
>         if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
>         if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
>         return n + (i >>> 1);
>     }
>
> But it's hard to resist the urge to optimize out a branch:
>
>     static int ntz_inlineNlz6(int i) {
>         i = ~i & (i - 1);
>         if (i <= 0) return i & 32;
>         int n = 1;
>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>         if (i >= 1 <<  8) { n +=  8; i >>>=  8; }
>         if (i >= 1 <<  4) { n +=  4; i >>>=  4; }
>         if (i >= 1 <<  2) { n +=  2; i >>>=  2; }
>         return n + (i >>> 1);
>     }
>

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Mon Aug 13 17:58:01 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Aug 2018 10:58:01 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
 <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
 <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>
 <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>
Message-ID: <CA+kOe0_Q9J2Zb04LM_L6C9Xy7o0HPXhc5_6HLG+ohqayvR1tog@mail.gmail.com>

On Mon, Aug 13, 2018 at 10:10 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hi Martin!
>
> Good point about the command line flags, thanks!
>
> These variants are close to numberOfTrailingZeros_07 that I've already
> tested, though you did better by saving one arithmetic operation at the
> return line!
>
>
Right. At this point

        return n + i - (i >> 1);


i is either 1 or 3, and

i - (i >> 1)

is equivalent to

1 + (i >>> 1)

so just initialize n to 1 instead.  Very much like
Integer.numberOfLeadingZeros does.

From ivan.gerasimov at oracle.com  Mon Aug 13 19:09:32 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 13 Aug 2018 12:09:32 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
 <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
 <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>
 <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>
Message-ID: <c6be9994-91a2-2e52-3519-d22181c2c73a@oracle.com>

Okay, your last variant is the winner :)

Here's the updated webrev, benchmark and the graphs:

http://cr.openjdk.java.net/~igerasim/8209171/02/webrev/
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-04-client.png
http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/bench-int-04-server.png

With kind regards,
Ivan

On 8/13/18 10:10 AM, Ivan Gerasimov wrote:
> Hi Martin!
>
> Good point about the command line flags, thanks!
>
> These variants are close to numberOfTrailingZeros_07 that I've already 
> tested, though you did better by saving one arithmetic operation at 
> the return line!
>
> I'll rerun the benchmarks.
>
> With kind regards,
>
> Ivan
>
>
> On 8/13/18 7:56 AM, Martin Buchholz wrote:
>> The number of plausible variants is astonishing!
>>
>> ---
>>
>> Your use of -client and -server is outdated, which explains why you 
>> get the same results for both (-client is ignored).
>>
>> I'm not sure what's blessed by hotspot team, but for C1 I use 
>> -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and for C2 I use 
>> -XX:-TieredCompilation -server
>>
>> ---
>>
>> Now I understand the advantage of using ~i & (i - 1): the subsequent 
>> zero check is a short-circuit for all odd numbers, better than i & 
>> -i, which explains your results - they depend on being able to 
>> short-circuit.
>>
>> So just use a more faithful inlining of nlz without trying to improve 
>> on it.
>>
>>     static int ntz_inlineNlz5(int i) {
>>         i = ~i & (i - 1);
>>         if (i <= 0)
>>             return (i == 0) ? 0 : 32;
>>         int n = 1;
>>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>         if (i >= 1 <<  8) { n +=  8; i >>>= 8; }
>>         if (i >= 1 <<  4) { n +=  4; i >>>= 4; }
>>         if (i >= 1 <<  2) { n +=  2; i >>>= 2; }
>>         return n + (i >>> 1);
>>     }
>>
>> But it's hard to resist the urge to optimize out a branch:
>>
>>     static int ntz_inlineNlz6(int i) {
>>         i = ~i & (i - 1);
>>         if (i <= 0) return i & 32;
>>         int n = 1;
>>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>         if (i >= 1 <<  8) { n +=  8; i >>>= 8; }
>>         if (i >= 1 <<  4) { n +=  4; i >>>= 4; }
>>         if (i >= 1 <<  2) { n +=  2; i >>>= 2; }
>>         return n + (i >>> 1);
>>     }
>>
>

-- 
With kind regards,
Ivan Gerasimov


From sean.mullan at oracle.com  Mon Aug 13 19:44:06 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 13 Aug 2018 15:44:06 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <4c6b969405364fc394459e8cd1789842@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <4c6b969405364fc394459e8cd1789842@sap.com>
Message-ID: <2dcec1bd-a08b-67b3-70bd-2686fede52ce@oracle.com>

On 8/13/18 11:18 AM, Baesken, Matthias wrote:
>> As Chris and Alan mentioned, you should move the parsing of the property
>> to a more general location so it can be used by other code that uses
>> this property.
> Hi Sean, Thanks for  the input  and comments .
> Could we do the moving  of the  property parsing    do  in a followup CR, I would prefer this .

I think it should be done as part of this issue. It is too late to get 
this into JDK 11, so I think it is better to take the time now to do the 
code restructuring.

Thanks,
Sean

From brian.burkhalter at oracle.com  Mon Aug 13 21:26:51 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 13 Aug 2018 14:26:51 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
Message-ID: <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>

Hi Bernard,

I updated the patch per your suggestions and it checks out on our systems.

http://cr.openjdk.java.net/~bpb/8207744/webrev.04/

Thanks,

Brian

On Aug 10, 2018, at 6:20 AM, B. Blaser <bsrbnd at gmail.com> wrote:

> Among the files you suggest to fix, only the following ones are still
> using 'readdir64' for other systems than AIX:


From martinrb at google.com  Mon Aug 13 23:18:03 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Aug 2018 16:18:03 -0700
Subject: RFR 8209171 : Simplify Java implementation of
 Integer/Long.numberOfTrailingZeros()
In-Reply-To: <c6be9994-91a2-2e52-3519-d22181c2c73a@oracle.com>
References: <aa6e8226-6762-8a2f-99d3-78827fd357ae@oracle.com>
 <CA+kOe0-Cpxdmexz81V7nU2xi0+RSJymmWoTD49UFoK3EFgUQeQ@mail.gmail.com>
 <cfbebf3c-a634-9d48-d93c-94534b655e1e@oracle.com>
 <CA+kOe0-TnhQ86+i3qnFVXL76iNfWALwksP_Ud9VwXYthOYXZzQ@mail.gmail.com>
 <e57e3b74-38f6-ab85-ff6b-ac037191e510@oracle.com>
 <CA+kOe08qRfg=pxSr2xR3k-cqVPk5t6qvg5Ui_vD9HJZXM7Jurg@mail.gmail.com>
 <43018047-c1a3-70ff-e56e-31b12e1d4dea@oracle.com>
 <CA+kOe0_ymq_4D4pqn8xtjqMQkf6AdDiTuO+1Nqpa3tq_5tRq1g@mail.gmail.com>
 <8119d2f9-3b36-6f31-28ca-f5056c036db7@oracle.com>
 <CA+kOe0-U1pDgGHdHfuLBVE0RbDALx3Q6yxSjVvQp66X5mz+pVQ@mail.gmail.com>
 <b5a17115-1486-9496-f06b-5080f0ca7489@oracle.com>
 <c6be9994-91a2-2e52-3519-d22181c2c73a@oracle.com>
Message-ID: <CA+kOe09eXY6LiX0KAhZ6z38gno-pmQomtgAOQ2g94OrtAKNJQw@mail.gmail.com>

Approved!

There was a lot of benchmarking work, so I'd like to see the jmh benchmark
checked in.
Especially since the exact variant we eventually settled on is not in
Hacker's Delight.

On Mon, Aug 13, 2018 at 12:09 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Okay, your last variant is the winner :)
>
> Here's the updated webrev, benchmark and the graphs:
>
> http://cr.openjdk.java.net/~igerasim/8209171/02/webrev/
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/MyBenchmark.java
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/be
> nch-int-04-client.png
> http://cr.openjdk.java.net/~igerasim/8209171/02/bench/int/be
> nch-int-04-server.png
>
> With kind regards,
> Ivan
>
>
> On 8/13/18 10:10 AM, Ivan Gerasimov wrote:
>
>> Hi Martin!
>>
>> Good point about the command line flags, thanks!
>>
>> These variants are close to numberOfTrailingZeros_07 that I've already
>> tested, though you did better by saving one arithmetic operation at the
>> return line!
>>
>> I'll rerun the benchmarks.
>>
>> With kind regards,
>>
>> Ivan
>>
>>
>> On 8/13/18 7:56 AM, Martin Buchholz wrote:
>>
>>> The number of plausible variants is astonishing!
>>>
>>> ---
>>>
>>> Your use of -client and -server is outdated, which explains why you get
>>> the same results for both (-client is ignored).
>>>
>>> I'm not sure what's blessed by hotspot team, but for C1 I use
>>> -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and for C2 I use
>>> -XX:-TieredCompilation -server
>>>
>>> ---
>>>
>>> Now I understand the advantage of using ~i & (i - 1): the subsequent
>>> zero check is a short-circuit for all odd numbers, better than i & -i,
>>> which explains your results - they depend on being able to short-circuit.
>>>
>>> So just use a more faithful inlining of nlz without trying to improve on
>>> it.
>>>
>>>     static int ntz_inlineNlz5(int i) {
>>>         i = ~i & (i - 1);
>>>         if (i <= 0)
>>>             return (i == 0) ? 0 : 32;
>>>         int n = 1;
>>>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>>         if (i >= 1 <<  8) { n +=  8; i >>>= 8; }
>>>         if (i >= 1 <<  4) { n +=  4; i >>>= 4; }
>>>         if (i >= 1 <<  2) { n +=  2; i >>>= 2; }
>>>         return n + (i >>> 1);
>>>     }
>>>
>>> But it's hard to resist the urge to optimize out a branch:
>>>
>>>     static int ntz_inlineNlz6(int i) {
>>>         i = ~i & (i - 1);
>>>         if (i <= 0) return i & 32;
>>>         int n = 1;
>>>         if (i >= 1 << 16) { n += 16; i >>>= 16; }
>>>         if (i >= 1 <<  8) { n +=  8; i >>>= 8; }
>>>         if (i >= 1 <<  4) { n +=  4; i >>>= 4; }
>>>         if (i >= 1 <<  2) { n +=  2; i >>>= 2; }
>>>         return n + (i >>> 1);
>>>     }
>>>
>>>
>>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From igor.ignatyev at oracle.com  Tue Aug 14 00:40:25 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 13 Aug 2018 17:40:25 -0700
Subject: RFR(XXS) : 8209382 : [error-prone] HashtableContains in
 sun/rmi/server/ActivationGroupImpl.java
In-Reply-To: <133be988-3a7f-906c-0f23-47b9e84ff5d9@oracle.com>
References: <12AE4B22-1100-4B44-B53A-4AC94A33F9FF@oracle.com>
 <133be988-3a7f-906c-0f23-47b9e84ff5d9@oracle.com>
Message-ID: <BC486763-278B-44A8-99E4-5EBBD3EC7583@oracle.com>

Hi Roger,

thanks for review.

-- Igor

> On Aug 10, 2018, at 1:49 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Igor,
> 
> Looks fine
> 
> Roger
> 
> On 8/10/18 4:22 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
>>> 2 lines changed: 0 ins; 0 del; 2 mod;
>> Hi all,
>> 
>> could you please review this one-line patch for the error reported by error-prone?
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209382
>> webrev: http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
>> 
>> Thanks,
>> -- Igor
> 


From mandy.chung at oracle.com  Tue Aug 14 01:09:04 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 13 Aug 2018 18:09:04 -0700
Subject: RFR8194230, jdk/internal/jrtfs/remote/RemoteRuntimeImageTest.java
 fails with NPE
In-Reply-To: <284d8529-423e-7d7a-af87-01016ded88e5@oracle.com>
References: <73b18b56-5266-4274-f05a-75fcb87eef44@oracle.com>
 <181961ff-573a-dbff-7ba9-59d5e3afb980@oracle.com>
 <284d8529-423e-7d7a-af87-01016ded88e5@oracle.com>
Message-ID: <f9f7b104-2730-cfe7-ba49-d5cfd2a6f896@oracle.com>



On 8/13/18 2:09 AM, Felix Yang wrote:
> Hi Alan,
> 
>  ??? please review the update patch, and reduced checking as suggested:
> 
> http://cr.openjdk.java.net/~xiaofeya/8194230/webrev.01/

This looks okay.

Mandy

From bsrbnd at gmail.com  Tue Aug 14 11:13:24 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 14 Aug 2018 13:13:24 +0200
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
Message-ID: <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>

Seems quite good to me, last notes:

1) dealing with 'stat/stat64' in 'UnixFileSystem_md.c' might be
outside the scope of this fix (?) even if fully pertinent per [1]. In
the same file, I think '#define dirent dirent64' is probably missing
for AIX.

2) I guess '#if defined(_AIX) ...' is now missing in 'OperatingSystemImpl.c':
#if defined(_AIX)
  #define DIR DIR64
  #define dirent dirent64
  #define opendir opendir64
  #define readdir readdir64
  #define closedir closedir64
#endif

You'll probably need some more reviews especially for other systems
than Linux 64-bit.

Thanks,
Bernard

[1] https://www.gnu.org/software/libc/manual/html_node/Reading-Attributes.html


On 13 August 2018 at 23:26, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> Hi Bernard,
>
> I updated the patch per your suggestions and it checks out on our systems.
>
> http://cr.openjdk.java.net/~bpb/8207744/webrev.04/
>
> Thanks,
>
> Brian
>
> On Aug 10, 2018, at 6:20 AM, B. Blaser <bsrbnd at gmail.com> wrote:
>
> Among the files you suggest to fix, only the following ones are still
> using 'readdir64' for other systems than AIX:
>
>

From adinn at redhat.com  Tue Aug 14 11:34:09 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 14 Aug 2018 12:34:09 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
 <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>
Message-ID: <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>

Hi Alan,

Thanks for looking at this and apologies for the delayed response (c/o
our annual Red Hat OpenJDK team meeting taking place all last week).

On 06/08/18 10:29, Alan Bateman wrote:

> The current iteration, to introduce new MapMode values, is not too bad
> but it makes me wonder if we could avoid new modes altogether by
> detecting that the file is backed by NVM. Is there a fcntl cmd or some
> other syscall that can be used to detect this? I'm asking because it
> would open the potential to discuss limiting the API changes to just
> MappedByteBuffer.

That might well be a cleaner, simpler model. However, there are two
issues with it:

Firstly, there does not appear to be a supported way to identify whether
or not a device -- or a file associated with the device -- is mappable
using MAP_SYNC. A hack would be to attempt a map call with MAP_SYNC and
see if it failed with a suitably revealing errno code but that seems
rather gross and, perhaps, unreliable (the same errno code might occur
for other reasons).

Secondly, it may not always be the case that users will want to map an
NVM device with MAP_SYNC and rely on explicit line-by-line writeback. If
a user only needs block-level syncing then she might prefer to map the
file as a normal device and rely on force to perform block level
writeback via the driver.

> In the draft JEP then the Summary, Goals, Non-Goals, Success Metrics,
> and Motivation sections read well. The Description section is very wordy
> and includes a lot of implementation detail that I assume will be
> removed before it is submitted (my guess is that it can be distilled
> down to a couple of paragraphs). As a comparison, the API surface in JEP
> 337 is much larger but we were able to reduce the text down to a few
> paragraphs. The Testing sectioning highlights the challenges and reminds
> me that we have several features that will need maintainers to
> continuously test to ensure that a feature doesn't bit rot (SCTP and the
> proposed APIs for RDMA sockets are in the same boat).

I will be happy to perform this trimming down. The detail was merely to
ensure the draft implementation was understandable.

> Are you familiar with BufferPoolMXBean which can be used by management
> tools to monitor pool of buffers? I'm wondering if we should introduce a
> new pool for NVM so that it doesn't show up in the "mapped" pool.

I am not familiar with BufferPoolMXBean but I will investigate.

I'm agnostic as to whether to track NVM buffers separate from other
buffers but I am happy to consider adding this as a requirement.
However, before doing so, can you explain further why there is a need to
keep this case separate? In particular, I am puzzled by your use of
"mapped". The NVM memory is definitely mapped although obviously it is
of a different type to say private mapped volatile memory or a mapped
disk file. Also, are these latter cases distinguished as far as
BufferPoolMXBean bean counting is concerned? NVM seems to me to fall
somewhere between the two.

> I can't tell from this thread if you are looking for detailed feedback
> on the current patch. A couple of random things:

I guess its not the primary concern (which is to get the JEP submitted)
but comments are welcome now or later.

> - there are residual references to map_persistent in several places
> - MappedByteBuffer.force will need to specify IAE
> - The new methods are missing @since
> - I think it would be clearer if MappedByteBuffer.force use "region"
> rather than "sub-region" as it is used in the context of the buffer, not
> the original file.
> - There will be round of clean up needed to the changes to java.base to
> get the javadoc and code consistent with the javadoc/code in this area.
> I assume we'll get back to that when the patch is closer to review.
Ok, I'll post an update when I have trimmed the implementation details
the JEP and tweaked the code according to the above comments. Thank you
for your feedback.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From Roger.Riggs at Oracle.com  Tue Aug 14 14:00:43 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Aug 2018 10:00:43 -0400
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess
 contains bug
Message-ID: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>

Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
Catch wrap around in very large wait times and saturate at Long.MAX_VALUE.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8208715

Thanks, Roger


From scolebourne at joda.org  Tue Aug 14 14:07:41 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 14 Aug 2018 15:07:41 +0100
Subject: MethodHandles.Lookup.defineResource?
Message-ID: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>

A new method MethodHandles.Lookup defineClass() was added recently.
But what about a defineResource? For adding a new resource to the
classpath (such as a .txt file). I just needed such a thing, and
though undoubtedly rare, all the recommended solutions use reflection
and setAccessible().

thanks
Stephen

From martinrb at google.com  Tue Aug 14 14:47:34 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Aug 2018 07:47:34 -0700
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
Message-ID: <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>

hi Roger,

 509         if (deadline <= 0) { 510             deadline =
Long.MAX_VALUE; 511         }


This must be wrong.  Nanotime wraparound is normal in this sort of code.

---

We ought to be able to delegate the fiddling with nanos to
TimeUnit.timedWait.

Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
If not, is there a bug in TimeUnit.timedWait?

It's good to add a test for this.  I've tried hard in similar tests to
avoid sleep and to add variants where the target thread is interrupted
before and after starting to wait.  Testing pre-interrupt is easy - the
thread can interrupt itself.  BlockingQueueTest.testTimedPollWithOffer is
an example.




On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
> Catch wrap around in very large wait times and saturate at Long.MAX_VALUE.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8208715
>
> Thanks, Roger
>
>

From mandy.chung at oracle.com  Tue Aug 14 15:24:36 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 14 Aug 2018 08:24:36 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
Message-ID: <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>

Hi Adam,

Have you tried Peter's suggestion if an empty static method taking an
Object parameter?  Does it work for you?

Your proposed approach seems fine and I would suggest to put the
check in a static keepAlive method that will make it explicitly.

Mandy

On 8/10/18 8:42 AM, Adam Farley8 wrote:
> Hi All,
> 
> This bug could be fixed by comparing the Class Loader with a blank
> static volatile Object (defined outside the method scope) at the
> end of the getBundleImpl class.
> 
> E.g.
> 
> -----------------------------------------
> +1322
>      /**
>       * volatile reference object to guard the ClassLoader object
>       * being garbage collected before getBundleImpl() method completes
>       * the caching and retrieving of requested Resourcebundle object
>       */
>      private static volatile Object vo = new Object();
> 
> 
> +1400
> //Should never be true. Using the loader here prevents it being GC'd.
>              if (loader == vo) throw new Error("Unexpected error.");
> -----------------------------------------
> 
> Will upload a webrev after debate.
> 
> - Adam
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 

From Roger.Riggs at Oracle.com  Tue Aug 14 16:48:06 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Aug 2018 12:48:06 -0400
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
Message-ID: <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>

Hi Martin,

I updated the webrev with the suggestions.

On 8/14/2018 10:47 AM, Martin Buchholz wrote:
> hi Roger,
>
> 509 if (deadline <= 0) {
> 510 deadline = Long.MAX_VALUE;
> 511 }
>
> This must be wrong.? Nanotime wraparound is normal in this sort of code.
ok, this reader didn't make that assumption
>
> ---
>
> We ought to be able to delegate the fiddling with nanos to 
> TimeUnit.timedWait.
>
> Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
> If not, is there a bug in TimeUnit.timedWait?
That works except on Windows, that does not use wait().

>
> It's good to add a test for this.? I've tried hard in similar tests to 
> avoid sleep and to add variants where the target thread is interrupted 
> before and after starting to wait.? Testing pre-interrupt is easy - 
> the thread can interrupt itself.? 
> BlockingQueueTest.testTimedPollWithOffer is an example.
I added a test, using the same logic as the existing tests for the 
Long.MAX_VALUE case

Thanks, Roger

>
>
>
>
> On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>     Catch wrap around in very large wait times and saturate at
>     Long.MAX_VALUE.
>
>     Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/>
>
>     Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8208715
>     <https://bugs.openjdk.java.net/browse/JDK-8208715>
>
>     Thanks, Roger
>
>


From martinrb at google.com  Tue Aug 14 17:22:17 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Aug 2018 10:22:17 -0700
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
 <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
Message-ID: <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>

Thanks, Roger.  I approve this version, although as always I have comments.

 520     private static native void waitForTimeoutInterruptibly(
 521         long handle, long timeout);

The units being used should be obvious from the signature - rename timeout
to timeoutMillis.  But even better is to push the support for nanos into
the utility method, so change this native method to accept a timeoutNanos.

2465             Thread.sleep(1000);

I hate sleeps, and I would just delete this one - I don't think the test
relies on it (and if it did, one second is not long enough!).

2454                     try {
2455                         aboutToWaitFor.countDown();
2456                         boolean result = p.waitFor(Long.MAX_VALUE,
TimeUnit.MILLISECONDS);
2457                         fail("waitFor() wasn't interrupted, its return
value was: " + result);
2458                     } catch (InterruptedException success) {
2459                     } catch (Throwable t) { unexpected(t); }

It's easy to add a self-interrupt variant inside the run method

Thread.currentThread().interrupt(); ...

(TODO: Basic.java is in need of a re-write - mea culpa ...)





On Tue, Aug 14, 2018 at 9:48 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Martin,
>
> I updated the webrev with the suggestions.
>
> On 8/14/2018 10:47 AM, Martin Buchholz wrote:
>
> hi Roger,
>
>  509         if (deadline <= 0) { 510             deadline = Long.MAX_VALUE; 511         }
>
>
> This must be wrong.  Nanotime wraparound is normal in this sort of code.
>
> ok, this reader didn't make that assumption
>
>
> ---
>
> We ought to be able to delegate the fiddling with nanos to
> TimeUnit.timedWait.
>
> Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
> If not, is there a bug in TimeUnit.timedWait?
>
> That works except on Windows, that does not use wait().
>
>
> It's good to add a test for this.  I've tried hard in similar tests to
> avoid sleep and to add variants where the target thread is interrupted
> before and after starting to wait.  Testing pre-interrupt is easy - the
> thread can interrupt itself.  BlockingQueueTest.testTimedPollWithOffer is
> an example.
>
> I added a test, using the same logic as the existing tests for the
> Long.MAX_VALUE case
>
> Thanks, Roger
>
>
>
>
>
> On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>> Catch wrap around in very large wait times and saturate at Long.MAX_VALUE.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8208715
>>
>> Thanks, Roger
>>
>>
>
>

From mearvk at outlook.com  Tue Aug 14 17:31:55 2018
From: mearvk at outlook.com (mr rupplin)
Date: Tue, 14 Aug 2018 17:31:55 +0000
Subject: OpenJDK 9 - Make (no deprecations flag setting)
Message-ID: <SN6PR07MB5022381423F15408A27503E7DA380@SN6PR07MB5022.namprd07.prod.outlook.com>

Where in Makefile do we add this - to suppress deprecation warnings - to our personal builds.

Thanks.

MR

From Roger.Riggs at Oracle.com  Tue Aug 14 19:59:48 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Aug 2018 15:59:48 -0400
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
 <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
 <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>
Message-ID: <3d45ffdf-3a84-7f1a-8bdd-e510b9291880@Oracle.com>

Hi Martin,

Updated with suggestions:
 ?http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/index.html

On 8/14/2018 1:22 PM, Martin Buchholz wrote:
> Thanks, Roger.? I approve this version, although as always I have 
> comments.
>
> ?520? ? ?private static native void waitForTimeoutInterruptibly(
> ?521? ? ? ? ?long handle, long timeout);
>
> The units being used should be obvious from the signature - rename 
> timeout to timeoutMillis.
Done
> But even better is to push the support for nanos into the utility 
> method, so change this native method to accept a timeoutNanos.
A bit far from the original issue and it might take a bit more time.
>
> 2465? ? ? ? ? ? ?Thread.sleep(1000);
>
> I hate sleeps, and I would just delete this one - I don't think the 
> test relies on it (and if it did, one second is not long enough!).
Done.? (And in the test case used for the copy/paste of the new test).
>
> 2454? ? ? ? ? ? ? ? ? ? ?try {
> 2455? ? ? ? ? ? ? ? ? ? ? ? ?aboutToWaitFor.countDown();
> 2456? ? ? ? ? ? ? ? ? ? ? ? ?boolean result = 
> p.waitFor(Long.MAX_VALUE, TimeUnit.MILLISECONDS);
> 2457? ? ? ? ? ? ? ? ? ? ? ? ?fail("waitFor() wasn't interrupted, its 
> return value was: " + result);
> 2458? ? ? ? ? ? ? ? ? ? ?} catch (InterruptedException success) {
> 2459? ? ? ? ? ? ? ? ? ? ?} catch (Throwable t) { unexpected(t); }
>
> It's easy to add a self-interrupt variant inside the run method
>
> Thread.currentThread().interrupt(); ...
ok, and will run all the tests again.

Thanks, Roger

>
> (TODO: Basic.java is in need of a re-write - mea culpa ...)
>
>
>
>
>
> On Tue, Aug 14, 2018 at 9:48 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     I updated the webrev with the suggestions.
>
>     On 8/14/2018 10:47 AM, Martin Buchholz wrote:
>>     hi Roger,
>>
>>     509 if (deadline <= 0) {
>>     510 deadline = Long.MAX_VALUE;
>>     511 }
>>
>>     This must be wrong.? Nanotime wraparound is normal in this sort
>>     of code.
>     ok, this reader didn't make that assumption
>>
>>     ---
>>
>>     We ought to be able to delegate the fiddling with nanos to
>>     TimeUnit.timedWait.
>>
>>     Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
>>     If not, is there a bug in TimeUnit.timedWait?
>     That works except on Windows, that does not use wait().
>
>>
>>     It's good to add a test for this.? I've tried hard in similar
>>     tests to avoid sleep and to add variants where the target thread
>>     is interrupted before and after starting to wait.? Testing
>>     pre-interrupt is easy - the thread can interrupt itself.?
>>     BlockingQueueTest.testTimedPollWithOffer is an example.
>     I added a test, using the same logic as the existing tests for the
>     Long.MAX_VALUE case
>
>     Thanks, Roger
>
>>
>>
>>
>>
>>     On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs
>>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>         Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>>         Catch wrap around in very large wait times and saturate at
>>         Long.MAX_VALUE.
>>
>>         Webrev:
>>         http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>>         <http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/>
>>
>>         Issue:
>>         https://bugs.openjdk.java.net/browse/JDK-8208715
>>         <https://bugs.openjdk.java.net/browse/JDK-8208715>
>>
>>         Thanks, Roger
>>
>>
>
>


From brian.burkhalter at oracle.com  Tue Aug 14 20:34:59 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Aug 2018 13:34:59 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
Message-ID: <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>

Hi Bernard,

On Aug 14, 2018, at 4:13 AM, B. Blaser <bsrbnd at gmail.com> wrote:

> Seems quite good to me, last notes:
> 
> 1) dealing with 'stat/stat64' in 'UnixFileSystem_md.c' might be
> outside the scope of this fix (?) even if fully pertinent per [1].

It might be slightly out of scope but I think it?s OK as stat64 was defined inside an
#if defined(_ALLBSD_SOURCE) conditional compilation block.

> In the same file, I think '#define dirent dirent64' is probably missing
> for AIX.

Fixed.

> 2) I guess '#if defined(_AIX) ...' is now missing in 'OperatingSystemImpl.c':
> #if defined(_AIX)
>  #define DIR DIR64
>  #define dirent dirent64
>  #define opendir opendir64
>  #define readdir readdir64
>  #define closedir closedir64
> #endif

Fixed.

Webrev updated in place: http://cr.openjdk.java.net/~bpb/8207744/webrev.04/.

Checks out on Linux-x64, macOS, Solaris-sparcv9, Windows-x64.

> You'll probably need some more reviews especially for other systems
> than Linux 64-bit.

It would not hurt. In any case I do not yet have a Reviewer approval.

Thanks,

Brian

From martinrb at google.com  Tue Aug 14 22:14:05 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Aug 2018 15:14:05 -0700
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <3d45ffdf-3a84-7f1a-8bdd-e510b9291880@Oracle.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
 <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
 <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>
 <3d45ffdf-3a84-7f1a-8bdd-e510b9291880@Oracle.com>
Message-ID: <CA+kOe0_BEfQ0iWJUarUe5qhT7v5ZgYG11ik=7FNCjLW5wzmgag@mail.gmail.com>

Looks good to me ... but ...

my intent was that the self-interrupt was added in __addition__ to
interrupt by other thread, because there is often different code to handle
pre-existing interrupt.  As with BlockingQueueTest.testTimedPollWithOffer.

                public void run() {
                    Thread.currentThread().interrupt();
                    try {
                        boolean result = p.waitFor(Long.MAX_VALUE,
TimeUnit.MILLISECONDS);
                        fail("Should have thrown InterruptedException");
                    } catch (InterruptedException success) {
                    } catch (Throwable t) { unexpected(t); }

                    try {
                        aboutToWaitFor.countDown();
                        boolean result = p.waitFor(Long.MAX_VALUE,
TimeUnit.MILLISECONDS);
                        fail("Should have thrown InterruptedException");
                    } catch (InterruptedException success) {
                    } catch (Throwable t) { unexpected(t); }




On Tue, Aug 14, 2018 at 12:59 PM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Martin,
>
> Updated with suggestions:
>  http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/index.html
>
> On 8/14/2018 1:22 PM, Martin Buchholz wrote:
>
> Thanks, Roger.  I approve this version, although as always I have
> comments.
>
>  520     private static native void waitForTimeoutInterruptibly(
>  521         long handle, long timeout);
>
> The units being used should be obvious from the signature - rename timeout
> to timeoutMillis.
>
> Done
>
> But even better is to push the support for nanos into the utility method,
> so change this native method to accept a timeoutNanos.
>
> A bit far from the original issue and it might take a bit more time.
>
>
> 2465             Thread.sleep(1000);
>
> I hate sleeps, and I would just delete this one - I don't think the test
> relies on it (and if it did, one second is not long enough!).
>
> Done.  (And in the test case used for the copy/paste of the new test).
>
>
> 2454                     try {
> 2455                         aboutToWaitFor.countDown();
> 2456                         boolean result = p.waitFor(Long.MAX_VALUE,
> TimeUnit.MILLISECONDS);
> 2457                         fail("waitFor() wasn't interrupted, its
> return value was: " + result);
> 2458                     } catch (InterruptedException success) {
> 2459                     } catch (Throwable t) { unexpected(t); }
>
> It's easy to add a self-interrupt variant inside the run method
>
> Thread.currentThread().interrupt(); ...
>
> ok, and will run all the tests again.
>
> Thanks, Roger
>
>
>
> (TODO: Basic.java is in need of a re-write - mea culpa ...)
>
>
>
>
>
> On Tue, Aug 14, 2018 at 9:48 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> I updated the webrev with the suggestions.
>>
>> On 8/14/2018 10:47 AM, Martin Buchholz wrote:
>>
>> hi Roger,
>>
>>  509         if (deadline <= 0) { 510             deadline = Long.MAX_VALUE; 511         }
>>
>>
>> This must be wrong.  Nanotime wraparound is normal in this sort of code.
>>
>> ok, this reader didn't make that assumption
>>
>>
>> ---
>>
>> We ought to be able to delegate the fiddling with nanos to
>> TimeUnit.timedWait.
>>
>> Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
>> If not, is there a bug in TimeUnit.timedWait?
>>
>> That works except on Windows, that does not use wait().
>>
>>
>> It's good to add a test for this.  I've tried hard in similar tests to
>> avoid sleep and to add variants where the target thread is interrupted
>> before and after starting to wait.  Testing pre-interrupt is easy - the
>> thread can interrupt itself.  BlockingQueueTest.testTimedPollWithOffer
>> is an example.
>>
>> I added a test, using the same logic as the existing tests for the
>> Long.MAX_VALUE case
>>
>> Thanks, Roger
>>
>>
>>
>>
>>
>> On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com>
>> wrote:
>>
>>> Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>>> Catch wrap around in very large wait times and saturate at
>>> Long.MAX_VALUE.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8208715
>>>
>>> Thanks, Roger
>>>
>>>
>>
>>
>
>

From hboehm at google.com  Tue Aug 14 23:22:27 2018
From: hboehm at google.com (Hans Boehm)
Date: Tue, 14 Aug 2018 16:22:27 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
Message-ID: <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>

I haven't looked at the details here, but comparing against a volatile is
not in general a portable way to keep an object live. Like empty static
methods, it may be fine in the current (OpenJDK) context.

Volatile loads have roach motel semantics and can be advanced past other
operations. The comparison can be done early, too, keeping only the
condition code. There is no guarantee the reference will still be around
when you expect it.

I haven't come up with a great compiler-independent replacement for
reachabilityFence.

On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com> wrote:

> Hi Adam,
>
> Have you tried Peter's suggestion if an empty static method taking an
> Object parameter?  Does it work for you?
>
> Your proposed approach seems fine and I would suggest to put the
> check in a static keepAlive method that will make it explicitly.
>
> Mandy
>
> On 8/10/18 8:42 AM, Adam Farley8 wrote:
> > Hi All,
> >
> > This bug could be fixed by comparing the Class Loader with a blank
> > static volatile Object (defined outside the method scope) at the
> > end of the getBundleImpl class.
> >
> > E.g.
> >
> > -----------------------------------------
> > +1322
> >      /**
> >       * volatile reference object to guard the ClassLoader object
> >       * being garbage collected before getBundleImpl() method completes
> >       * the caching and retrieving of requested Resourcebundle object
> >       */
> >      private static volatile Object vo = new Object();
> >
> >
> > +1400
> > //Should never be true. Using the loader here prevents it being GC'd.
> >              if (loader == vo) throw new Error("Unexpected error.");
> > -----------------------------------------
> >
> > Will upload a webrev after debate.
> >
> > - Adam
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
>

From mandy.chung at oracle.com  Tue Aug 14 23:54:53 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 14 Aug 2018 16:54:53 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
Message-ID: <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>

Thanks for the information.  Not sure what's the best option we can do
in 8u.  I think it's acceptable to have a fix that works in the
current context (like empty static method).

Thoughts?

Mandy

On 8/14/18 4:22 PM, Hans Boehm wrote:
> I haven't looked at the details here, but comparing against a volatile 
> is not in general a portable way to keep an object live. Like empty 
> static methods, it may be fine in the current (OpenJDK) context.
> 
> Volatile loads have roach motel semantics and can be advanced past other 
> operations. The comparison can be done early, too, keeping only the 
> condition code. There is no guarantee the reference will still be around 
> when you expect it.
> 
> I haven't come up with a great compiler-independent replacement for 
> reachabilityFence.
> 
> On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com 
> <mailto:mandy.chung at oracle.com>> wrote:
> 
>     Hi Adam,
> 
>     Have you tried Peter's suggestion if an empty static method taking an
>     Object parameter?? Does it work for you?
> 
>     Your proposed approach seems fine and I would suggest to put the
>     check in a static keepAlive method that will make it explicitly.
> 
>     Mandy
> 
>     On 8/10/18 8:42 AM, Adam Farley8 wrote:
>      > Hi All,
>      >
>      > This bug could be fixed by comparing the Class Loader with a blank
>      > static volatile Object (defined outside the method scope) at the
>      > end of the getBundleImpl class.
>      >
>      > E.g.
>      >
>      > -----------------------------------------
>      > +1322
>      >? ? ? /**
>      >? ? ? ?* volatile reference object to guard the ClassLoader object
>      >? ? ? ?* being garbage collected before getBundleImpl() method
>     completes
>      >? ? ? ?* the caching and retrieving of requested Resourcebundle object
>      >? ? ? ?*/
>      >? ? ? private static volatile Object vo = new Object();
>      >
>      >
>      > +1400
>      > //Should never be true. Using the loader here prevents it being GC'd.
>      >? ? ? ? ? ? ? if (loader == vo) throw new Error("Unexpected error.");
>      > -----------------------------------------
>      >
>      > Will upload a webrev after debate.
>      >
>      > - Adam
>      > Unless stated otherwise above:
>      > IBM United Kingdom Limited - Registered in England and Wales with
>     number
>      > 741598.
>      > Registered office: PO Box 41, North Harbour, Portsmouth,
>     Hampshire PO6 3AU
>      >
> 

From joe.darcy at oracle.com  Wed Aug 15 03:20:09 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 14 Aug 2018 20:20:09 -0700
Subject: JDK 12 RFR of 8176425: Add radix indication in NumberFormatException
 message for Integer.decode
Message-ID: <4313d260-13e0-6e0a-6045-9dd89f5913de@oracle.com>

Hello,

Please review the changes to address:

 ??? 8176425: Add radix indication in NumberFormatException message for 
Integer.decode
 ??? http://cr.openjdk.java.net/~darcy/8176425.0/

Basically the radix used for parsing an int or long is passed along to a 
factory method in the NumberFormatException class and the radix is 
included in the exception message for non-decimal radices.

Patch below.

Thanks,

-Joe


--- old/src/java.base/share/classes/java/lang/Integer.java 2018-08-14 
20:15:45.642000000 -0700
+++ new/src/java.base/share/classes/java/lang/Integer.java 2018-08-14 
20:15:45.498000000 -0700
@@ -635,11 +635,11 @@
 ???????????????????? negative = true;
 ???????????????????? limit = Integer.MIN_VALUE;
 ???????????????? } else if (firstChar != '+') {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }

 ???????????????? if (len == 1) { // Cannot have lone "+" or "-"
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? i++;
 ???????????? }
@@ -649,17 +649,17 @@
 ???????????????? // Accumulating negatively avoids surprises near MAX_VALUE
 ???????????????? int digit = Character.digit(s.charAt(i++), radix);
 ???????????????? if (digit < 0 || result < multmin) {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? result *= radix;
 ???????????????? if (result < limit + digit) {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? result -= digit;
 ???????????? }
 ???????????? return negative ? result : -result;
 ???????? } else {
-??????????? throw NumberFormatException.forInputString(s);
+??????????? throw NumberFormatException.forInputString(s, radix);
 ???????? }
 ???? }

@@ -745,7 +745,7 @@
 ???????????? }
 ???????????? return negative ? result : -result;
 ???????? } else {
-??????????? throw NumberFormatException.forInputString("");
+??????????? throw NumberFormatException.forInputString("", radix);
 ???????? }
 ???? }

@@ -842,7 +842,7 @@
 ???????????????? }
 ???????????? }
 ???????? } else {
-??????????? throw NumberFormatException.forInputString(s);
+??????????? throw NumberFormatException.forInputString(s, radix);
 ???????? }
 ???? }

--- old/src/java.base/share/classes/java/lang/Long.java 2018-08-14 
20:15:46.030000000 -0700
+++ new/src/java.base/share/classes/java/lang/Long.java 2018-08-14 
20:15:45.882000000 -0700
@@ -675,11 +675,11 @@
 ???????????????????? negative = true;
 ???????????????????? limit = Long.MIN_VALUE;
 ???????????????? } else if (firstChar != '+') {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }

 ???????????????? if (len == 1) { // Cannot have lone "+" or "-"
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? i++;
 ???????????? }
@@ -689,17 +689,17 @@
 ???????????????? // Accumulating negatively avoids surprises near MAX_VALUE
 ???????????????? int digit = Character.digit(s.charAt(i++),radix);
 ???????????????? if (digit < 0 || result < multmin) {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? result *= radix;
 ???????????????? if (result < limit + digit) {
-??????????????????? throw NumberFormatException.forInputString(s);
+??????????????????? throw NumberFormatException.forInputString(s, radix);
 ???????????????? }
 ???????????????? result -= digit;
 ???????????? }
 ???????????? return negative ? result : -result;
 ???????? } else {
-??????????? throw NumberFormatException.forInputString(s);
+??????????? throw NumberFormatException.forInputString(s, radix);
 ???????? }
 ???? }

@@ -945,7 +945,7 @@
 ???????????????? return result;
 ???????????? }
 ???????? } else {
-??????????? throw NumberFormatException.forInputString(s);
+??????????? throw NumberFormatException.forInputString(s, radix);
 ???????? }
 ???? }

@@ -1063,7 +1063,7 @@
 ???????????????? return result;
 ???????????? }
 ???????? } else {
-??????????? throw NumberFormatException.forInputString("");
+??????????? throw NumberFormatException.forInputString("", radix);
 ???????? }
 ???? }

--- old/src/java.base/share/classes/java/lang/NumberFormatException.java 
2018-08-14 20:15:46.418000000 -0700
+++ new/src/java.base/share/classes/java/lang/NumberFormatException.java 
2018-08-14 20:15:46.274000000 -0700
@@ -61,8 +61,11 @@
 ????? *
 ????? * @param?? s?? the input causing the error
 ????? */
-??? static NumberFormatException forInputString(String s) {
-??????? return new NumberFormatException("For input string: \"" + s + 
"\"");
+??? static NumberFormatException forInputString(String s, int radix) {
+??????? return new NumberFormatException("For input string: \"" + s + 
"\"" +
+??? ??? ??? ??? ??? ?(radix == 10 ?
+??? ??? ??? ??? ??? ? "" :
+??? ??? ??? ??? ??? ? " under radix " + radix));
 ???? }

 ???? /**
--- old/src/java.base/share/classes/java/lang/Package.java 2018-08-14 
20:15:46.790000000 -0700
+++ new/src/java.base/share/classes/java/lang/Package.java 2018-08-14 
20:15:46.646000000 -0700
@@ -286,7 +286,7 @@
 ???????? for (int i = 0; i < sa.length; i++) {
 ???????????? si[i] = Integer.parseInt(sa[i]);
 ???????????? if (si[i] < 0)
-??????????????? throw NumberFormatException.forInputString("" + si[i]);
+??????????????? throw NumberFormatException.forInputString("" + si[i], 10);
 ???????? }

 ???????? String [] da = desired.split("\\.", -1);
@@ -294,8 +294,8 @@
 ???????? for (int i = 0; i < da.length; i++) {
 ???????????? di[i] = Integer.parseInt(da[i]);
 ???????????? if (di[i] < 0)
-??????????????? throw NumberFormatException.forInputString("" + di[i]);
-??????? }
+??????????????? throw NumberFormatException.forInputString("" + di[i], 10);
+??? }

 ???????? int len = Math.max(di.length, si.length);
 ???????? for (int i = 0; i < len; i++) {


From joe.darcy at oracle.com  Wed Aug 15 03:59:34 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 14 Aug 2018 20:59:34 -0700
Subject: JDK 12 RFR of 5075463 : (enum) Serialized Form javadoc for
 java.lang.Enum is misleading
Message-ID: <71ba86dc-07de-89dd-2733-8a68d9666b45@oracle.com>

Hello,

Cleaning out an old bug, please review the CSR and fix for:

 ??? JDK-5075463 : (enum) Serialized Form javadoc for java.lang.Enum is 
misleading
 ??? http://cr.openjdk.java.net/~darcy/5075463.0/
 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8209524

The abstract class java.lang.Enum implements Serializable and is the 
superclass of all enum types. By default a serializable type is added to 
the serialized form page of the javadoc output. However, in the case of 
java.lang.Enum, including the type in the serialized form output is 
misleading since java.lang.Enum cannot be directly instantiated and enum 
types have special-cased handling in serialization. Adding a "@serial 
exclude" javadoc tag to the class-level javadoc of java.lang.Enum 
prevent an entry the the type in the serialized form page.

Patch below.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/lang/Enum.java 2018-08-14 
20:48:04.202000000 -0700
+++ new/src/java.base/share/classes/java/lang/Enum.java 2018-08-14 
20:48:04.058000000 -0700
@@ -45,6 +45,7 @@
 ? * java.util.EnumMap map} implementations are available.
 ? *
 ? * @param <E> The enum type subclass
+ * @serial exclude
 ? * @author? Josh Bloch
 ? * @author? Neal Gafter
 ? * @see???? Class#getEnumConstants()


From hboehm at google.com  Wed Aug 15 05:44:08 2018
From: hboehm at google.com (Hans Boehm)
Date: Tue, 14 Aug 2018 22:44:08 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
Message-ID: <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>

FWIW, since there was agreement that empty static methods should work in
this context, that seems like the best option to me.

On Tue, Aug 14, 2018 at 4:54 PM mandy chung <mandy.chung at oracle.com> wrote:

> Thanks for the information.  Not sure what's the best option we can do
> in 8u.  I think it's acceptable to have a fix that works in the
> current context (like empty static method).
>
> Thoughts?
>
> Mandy
>
> On 8/14/18 4:22 PM, Hans Boehm wrote:
> > I haven't looked at the details here, but comparing against a volatile
> > is not in general a portable way to keep an object live. Like empty
> > static methods, it may be fine in the current (OpenJDK) context.
> >
> > Volatile loads have roach motel semantics and can be advanced past other
> > operations. The comparison can be done early, too, keeping only the
> > condition code. There is no guarantee the reference will still be around
> > when you expect it.
> >
> > I haven't come up with a great compiler-independent replacement for
> > reachabilityFence.
> >
> > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com
> > <mailto:mandy.chung at oracle.com>> wrote:
> >
> >     Hi Adam,
> >
> >     Have you tried Peter's suggestion if an empty static method taking an
> >     Object parameter?  Does it work for you?
> >
> >     Your proposed approach seems fine and I would suggest to put the
> >     check in a static keepAlive method that will make it explicitly.
> >
> >     Mandy
> >
> >     On 8/10/18 8:42 AM, Adam Farley8 wrote:
> >      > Hi All,
> >      >
> >      > This bug could be fixed by comparing the Class Loader with a blank
> >      > static volatile Object (defined outside the method scope) at the
> >      > end of the getBundleImpl class.
> >      >
> >      > E.g.
> >      >
> >      > -----------------------------------------
> >      > +1322
> >      >      /**
> >      >       * volatile reference object to guard the ClassLoader object
> >      >       * being garbage collected before getBundleImpl() method
> >     completes
> >      >       * the caching and retrieving of requested Resourcebundle
> object
> >      >       */
> >      >      private static volatile Object vo = new Object();
> >      >
> >      >
> >      > +1400
> >      > //Should never be true. Using the loader here prevents it being
> GC'd.
> >      >              if (loader == vo) throw new Error("Unexpected
> error.");
> >      > -----------------------------------------
> >      >
> >      > Will upload a webrev after debate.
> >      >
> >      > - Adam
> >      > Unless stated otherwise above:
> >      > IBM United Kingdom Limited - Registered in England and Wales with
> >     number
> >      > 741598.
> >      > Registered office: PO Box 41, North Harbour, Portsmouth,
> >     Hampshire PO6 3AU
> >      >
> >
>

From jai.forums2013 at gmail.com  Wed Aug 15 05:58:54 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 15 Aug 2018 11:28:54 +0530
Subject: Arrays.asList returned List - Its modifying/write-through semantics
Message-ID: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>

Consider the following code:

import java.util.Arrays;
import java.util.List;

public class ArraysAsListTest {

??? public static void main(final String[] args) throws Exception {
??? ??? final List<String> someList = Arrays.asList(new String[] {"a"});
??? ??? System.out.println("Removed? " + someList.remove("a"));
??? }
}

It uses Arrays.asList to create a java.util.List and then calls a
list.remove(...) on it. This currently runs intothe following exception:

Exception in thread "main" java.lang.UnsupportedOperationException: remove
??? at java.base/java.util.Iterator.remove(Iterator.java:102)
??? at
java.base/java.util.AbstractCollection.remove(AbstractCollection.java:299)
??? at ArraysAsListTest.main(ArraysAsListTest.java:8)

The javadoc of Arrays.asList[1] states the following:

"Returns a fixed-size list backed by the specified array. (Changes to
the returned list "write through" to the array.)..."

and has no other mention of how it's supposed to behave with "write"
operations. Given that the javadoc states that the returned list is
"write through", would that mean a "add/removal" is allowed? Probably
not, because it does say it's a fixed size list.So the size altering,
write operations (like add(), remove()) aren't allowed, but that isn't
clear from the javadoc. So should the javadoc be updated to clarify the
semantics of what changes are "write through" and what changes are not
supported?

Furthermore, the UnsupportedOperationException isn't always thrown from
such a returned list. Consider this minor modification to the above code:

??? ??? final List<String> someList = Arrays.asList(new String[] {"a"});
??? ??? System.out.println("Removed? " + someList.remove("b"));

I add "a" and remove "b". This now runs fine without exceptions and
prints "Removed? false". Should the implementation just throw the
UnsupportedOperationException irrespective of whether or not the element
is contained insuch a returned list? If not, should that be made clear
in the javadoc (maybe same for addoperations)?

[1]
https://docs.oracle.com/javase/10/docs/api/java/util/Arrays.html#asList(T...)

-Jaikiran



From ivan.gerasimov at oracle.com  Wed Aug 15 07:50:14 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 15 Aug 2018 00:50:14 -0700
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
Message-ID: <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>

Hi Jaikiran!

The first part (the documentation clarification) was requested some time 
ago [1], so it may be eventually fixed.

[1] https://bugs.openjdk.java.net/browse/JDK-7033681

With respect to the second part (throwing UOE from remove(Object)), I 
agree with you that it would be more consistent to always throw it, 
regardless of the presence of the searched item.
However, it would introduce a change of behavior, so I think it's 
unlikely to happen.

It may make sense to update the documentation for all the 
structurally-modifying methods of Collection/List (remove(Object), 
retainAll, removeAll, clear) in the same way it was done for 
List.removeIf() here [2].

[2] https://bugs.openjdk.java.net/browse/JDK-8023339

With kind regards,
Ivan


On 8/14/18 10:58 PM, Jaikiran Pai wrote:
> Consider the following code:
>
> import java.util.Arrays;
> import java.util.List;
>
> public class ArraysAsListTest {
>
>      public static void main(final String[] args) throws Exception {
>          final List<String> someList = Arrays.asList(new String[] {"a"});
>          System.out.println("Removed? " + someList.remove("a"));
>      }
> }
>
> It uses Arrays.asList to create a java.util.List and then calls a
> list.remove(...) on it. This currently runs intothe following exception:
>
> Exception in thread "main" java.lang.UnsupportedOperationException: remove
>      at java.base/java.util.Iterator.remove(Iterator.java:102)
>      at
> java.base/java.util.AbstractCollection.remove(AbstractCollection.java:299)
>      at ArraysAsListTest.main(ArraysAsListTest.java:8)
>
> The javadoc of Arrays.asList[1] states the following:
>
> "Returns a fixed-size list backed by the specified array. (Changes to
> the returned list "write through" to the array.)..."
>
> and has no other mention of how it's supposed to behave with "write"
> operations. Given that the javadoc states that the returned list is
> "write through", would that mean a "add/removal" is allowed? Probably
> not, because it does say it's a fixed size list.So the size altering,
> write operations (like add(), remove()) aren't allowed, but that isn't
> clear from the javadoc. So should the javadoc be updated to clarify the
> semantics of what changes are "write through" and what changes are not
> supported?
>
> Furthermore, the UnsupportedOperationException isn't always thrown from
> such a returned list. Consider this minor modification to the above code:
>
>          final List<String> someList = Arrays.asList(new String[] {"a"});
>          System.out.println("Removed? " + someList.remove("b"));
>
> I add "a" and remove "b". This now runs fine without exceptions and
> prints "Removed? false". Should the implementation just throw the
> UnsupportedOperationException irrespective of whether or not the element
> is contained insuch a returned list? If not, should that be made clear
> in the javadoc (maybe same for addoperations)?
>
> [1]
> https://docs.oracle.com/javase/10/docs/api/java/util/Arrays.html#asList(T...)
>
> -Jaikiran
>
>
>

-- 
With kind regards,
Ivan Gerasimov


From jai.forums2013 at gmail.com  Wed Aug 15 10:57:37 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 15 Aug 2018 16:27:37 +0530
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
 <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
Message-ID: <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>

Hi Ivan,


On 15/08/18 1:20 PM, Ivan Gerasimov wrote:
> Hi Jaikiran!
>
> The first part (the documentation clarification) was requested some
> time ago [1], so it may be eventually fixed.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-7033681
Thank you for pointing to that one. I hadn't found it during my search
before sending this mail.

>
> With respect to the second part (throwing UOE from remove(Object)), I
> agree with you that it would be more consistent to always throw it,
> regardless of the presence of the searched item.
> However, it would introduce a change of behavior, so I think it's
> unlikely to happen.
I understand.
>
> It may make sense to update the documentation for all the
> structurally-modifying methods of Collection/List (remove(Object),
> retainAll, removeAll, clear) in the same way it was done for
> List.removeIf() here [2].
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8023339

I looked at that commit and yes, a similar @throws explaining the
UnsupportedOperationException will be helpful.

-Jai
>
> With kind regards,
> Ivan
>
>
> On 8/14/18 10:58 PM, Jaikiran Pai wrote:
>> Consider the following code:
>>
>> import java.util.Arrays;
>> import java.util.List;
>>
>> public class ArraysAsListTest {
>>
>> ???? public static void main(final String[] args) throws Exception {
>> ???????? final List<String> someList = Arrays.asList(new String[]
>> {"a"});
>> ???????? System.out.println("Removed? " + someList.remove("a"));
>> ???? }
>> }
>>
>> It uses Arrays.asList to create a java.util.List and then calls a
>> list.remove(...) on it. This currently runs intothe following exception:
>>
>> Exception in thread "main" java.lang.UnsupportedOperationException:
>> remove
>> ???? at java.base/java.util.Iterator.remove(Iterator.java:102)
>> ???? at
>> java.base/java.util.AbstractCollection.remove(AbstractCollection.java:299)
>>
>> ???? at ArraysAsListTest.main(ArraysAsListTest.java:8)
>>
>> The javadoc of Arrays.asList[1] states the following:
>>
>> "Returns a fixed-size list backed by the specified array. (Changes to
>> the returned list "write through" to the array.)..."
>>
>> and has no other mention of how it's supposed to behave with "write"
>> operations. Given that the javadoc states that the returned list is
>> "write through", would that mean a "add/removal" is allowed? Probably
>> not, because it does say it's a fixed size list.So the size altering,
>> write operations (like add(), remove()) aren't allowed, but that isn't
>> clear from the javadoc. So should the javadoc be updated to clarify the
>> semantics of what changes are "write through" and what changes are not
>> supported?
>>
>> Furthermore, the UnsupportedOperationException isn't always thrown from
>> such a returned list. Consider this minor modification to the above
>> code:
>>
>> ???????? final List<String> someList = Arrays.asList(new String[]
>> {"a"});
>> ???????? System.out.println("Removed? " + someList.remove("b"));
>>
>> I add "a" and remove "b". This now runs fine without exceptions and
>> prints "Removed? false". Should the implementation just throw the
>> UnsupportedOperationException irrespective of whether or not the element
>> is contained insuch a returned list? If not, should that be made clear
>> in the javadoc (maybe same for addoperations)?
>>
>> [1]
>> https://docs.oracle.com/javase/10/docs/api/java/util/Arrays.html#asList(T...)
>>
>>
>> -Jaikiran
>>
>>
>>
>



From adinn at redhat.com  Wed Aug 15 11:08:00 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 15 Aug 2018 12:08:00 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
 <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>
 <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>
Message-ID: <423fd99b-366f-7516-030e-f49d54b1d088@redhat.com>

Hi Alan,

Just a quick follow-up regarding the BufferPoolMXBean.

On 14/08/18 12:34, Andrew Dinn wrote:
> On 06/08/18 10:29, Alan Bateman wrote:
> 
>> Are you familiar with BufferPoolMXBean which can be used by management
>> tools to monitor pool of buffers? I'm wondering if we should introduce a
>> new pool for NVM so that it doesn't show up in the "mapped" pool.

Ok, so I have worked through the code and can see that MappedByteBuffers
for file device-based mappings (as opposed to direct memory mappings)
are currently counted by class Unmapper local to  FileChannelImpl and
the counts are made visible via a BufferPoolMXBean with name "mapped"
which is present in the list exposed by method getBufferPoolMXBeans() of
class ManagementFactoryHelper.

So, it seems what you are asking for is to keep separate tallies for
persistent MappedByteBuffers and expose them in a new BufferPoolMXBean
also inserted in the list exposed by getBufferPoolMXBeans. That sounds
like quite a good idea. It will leave any current code that wants to see
file mappings counting the 'same' thing yet still makes it possible to
count persistent mappings on their own and also tally all mappings by
iterating over all BufferPoolMXBeans in the list. I suggest giving the
bean the name "mapped_persistent".

I would happily update the JEP to include this as an 'API change' of
sorts but I'm not quite sure how to document it. Is this ok

 the JEP requires exposing a new java.lang.management.BufferPoolMXBean
with name "mapped_persistent" as a platform managed bean which can be
accessed using the existing ManagementFactory.getPlatformMXBeans() API

  the "mapped_persistent" bean records the buffer count, total bytes and
total allocation count stats for persistent MappedByteBuffers (i.e.
those mapped using MapMode READ_ONLY_PERSISTENT or READ_WRITE_PERSISTENT)

  these stats are collected separately from those currently collected in
the "mapped" BufferPoolMXBean which records the equivalent counts for
non-persistent MappedByteBuffers (i.e. those mapped using MapMode
READ_ONLY, READ_WRITE or PRIVATE)

It seems straightforward to implement this behaviour. If you like I can
add it to the next webrev?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From Lance.Andersen at oracle.com  Wed Aug 15 11:27:50 2018
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Aug 2018 07:27:50 -0400
Subject: JDK 12 RFR of 5075463 : (enum) Serialized Form javadoc for
 java.lang.Enum is misleading
In-Reply-To: <71ba86dc-07de-89dd-2733-8a68d9666b45@oracle.com>
References: <71ba86dc-07de-89dd-2733-8a68d9666b45@oracle.com>
Message-ID: <F9E60CD3-80EC-437A-AA39-EEFE59450F8B@oracle.com>

Hi Joe,

Added myself as a reviewer to the CSR and the change looks fine

On Aug 14, 2018, at 11:59 PM, joe darcy <joe.darcy at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8209524




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From Lance.Andersen at oracle.com  Wed Aug 15 11:33:09 2018
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Aug 2018 07:33:09 -0400
Subject: JDK 12 RFR of 8176425: Add radix indication in
 NumberFormatException message for Integer.decode
In-Reply-To: <4313d260-13e0-6e0a-6045-9dd89f5913de@oracle.com>
References: <4313d260-13e0-6e0a-6045-9dd89f5913de@oracle.com>
Message-ID: <E94B8433-46BB-4228-9368-0121069EC2D9@oracle.com>

Looks good Joe
On Aug 14, 2018, at 11:20 PM, joe darcy <joe.darcy at oracle.com> wrote:

> http://cr.openjdk.java.net/~darcy/8176425.0/




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From roger.riggs at oracle.com  Wed Aug 15 13:20:59 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Aug 2018 09:20:59 -0400
Subject: JDK 12 RFR of 5075463 : (enum) Serialized Form javadoc for
 java.lang.Enum is misleading
In-Reply-To: <F9E60CD3-80EC-437A-AA39-EEFE59450F8B@oracle.com>
References: <71ba86dc-07de-89dd-2733-8a68d9666b45@oracle.com>
 <F9E60CD3-80EC-437A-AA39-EEFE59450F8B@oracle.com>
Message-ID: <7ba5d03c-d564-5002-8c98-a64f7642bea6@oracle.com>

Hi Joe,

This change looks fine as the spec for serializing Enum's is in OIS and OOS.

However, the spec for serializing Enum's in ObjectInputStream and 
ObjectOutputStream is incomplete.
It does not mention that the class of the Enum is written to the stream 
before the enum name.
Please file an issue for that.

Regards, Roger


On 8/15/18 7:27 AM, Lance Andersen wrote:
> Hi Joe,
>
> Added myself as a reviewer to the CSR and the change looks fine
>
> On Aug 14, 2018, at 11:59 PM, joe darcy <joe.darcy at oracle.com> wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8209524
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>


From Roger.Riggs at Oracle.com  Wed Aug 15 14:06:18 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 15 Aug 2018 10:06:18 -0400
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <CA+kOe0_BEfQ0iWJUarUe5qhT7v5ZgYG11ik=7FNCjLW5wzmgag@mail.gmail.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
 <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
 <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>
 <3d45ffdf-3a84-7f1a-8bdd-e510b9291880@Oracle.com>
 <CA+kOe0_BEfQ0iWJUarUe5qhT7v5ZgYG11ik=7FNCjLW5wzmgag@mail.gmail.com>
Message-ID: <ec961fb4-547e-24ba-f705-5e50c3b89b76@Oracle.com>

Hi Martin,

ok, as a reliable pattern I see that to avoid knowing details of the 
implementation.
But the self interrupt seems redundant if the other is needed.

Updated:
 ? http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/

Thanks, Roger


On 8/14/2018 6:14 PM, Martin Buchholz wrote:
> Looks good to me ... but ...
>
> my intent was that the self-interrupt was added in __addition__ to 
> interrupt by other thread, because there is often different code to 
> handle pre-existing interrupt.? As with 
> BlockingQueueTest.testTimedPollWithOffer.
>
> ? ? ? ? ? ? ? ? public void run() {
> ? ? ? ? ? ? ? ? ? ? Thread.currentThread().interrupt();
> ? ? ? ? ? ? ? ? ? ? try {
> ? ? ? ? ? ? ? ? ? ? ? ? boolean result = p.waitFor(Long.MAX_VALUE, 
> TimeUnit.MILLISECONDS);
> ? ? ? ? ? ? ? ? ? ? ? ? fail("Should have thrown InterruptedException");
> ? ? ? ? ? ? ? ? ? ? } catch (InterruptedException success) {
> ? ? ? ? ? ? ? ? ? ? } catch (Throwable t) { unexpected(t); }
>
> ? ? ? ? ? ? ? ? ? ? try {
> ? ? ? ? ? ? ? ? ? ? ? ? aboutToWaitFor.countDown();
> ? ? ? ? ? ? ? ? ? ? ? ? boolean result = p.waitFor(Long.MAX_VALUE, 
> TimeUnit.MILLISECONDS);
> ? ? ? ? ? ? ? ? ? ? ? ? fail("Should have thrown InterruptedException");
> ? ? ? ? ? ? ? ? ? ? } catch (InterruptedException success) {
> ? ? ? ? ? ? ? ? ? ? } catch (Throwable t) { unexpected(t); }
>
>
>
>
> On Tue, Aug 14, 2018 at 12:59 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     Updated with suggestions:
>     http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/index.html
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/index.html>
>
>     On 8/14/2018 1:22 PM, Martin Buchholz wrote:
>>     Thanks, Roger.? I approve this version, although as always I have
>>     comments.
>>
>>     ?520? ? ?private static native void waitForTimeoutInterruptibly(
>>     ?521? ? ? ? ?long handle, long timeout);
>>
>>     The units being used should be obvious from the signature -
>>     rename timeout to timeoutMillis.
>     Done
>>     But even better is to push the support for nanos into the utility
>>     method, so change this native method to accept a timeoutNanos.
>     A bit far from the original issue and it might take a bit more time.
>>
>>     2465? ? ? ? ? ? ?Thread.sleep(1000);
>>
>>     I hate sleeps, and I would just delete this one - I don't think
>>     the test relies on it (and if it did, one second is not long
>>     enough!).
>     Done.? (And in the test case used for the copy/paste of the new test).
>>
>>     2454? ? ? ? ? ? ? ? ? ? ?try {
>>     2455 ?aboutToWaitFor.countDown();
>>     2456? ? ? ? ? ? ? ? ? ? ? ? ?boolean result =
>>     p.waitFor(Long.MAX_VALUE, TimeUnit.MILLISECONDS);
>>     2457? ? ? ? ? ? ? ? ? ? ? ? ?fail("waitFor() wasn't interrupted,
>>     its return value was: " + result);
>>     2458? ? ? ? ? ? ? ? ? ? ?} catch (InterruptedException success) {
>>     2459? ? ? ? ? ? ? ? ? ? ?} catch (Throwable t) { unexpected(t); }
>>
>>     It's easy to add a self-interrupt variant inside the run method
>>
>>     Thread.currentThread().interrupt(); ...
>     ok, and will run all the tests again.
>
>     Thanks, Roger
>
>
>>
>>     (TODO: Basic.java is in need of a re-write - mea culpa ...)
>>
>>
>>
>>
>>
>>     On Tue, Aug 14, 2018 at 9:48 AM, Roger Riggs
>>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>         Hi Martin,
>>
>>         I updated the webrev with the suggestions.
>>
>>         On 8/14/2018 10:47 AM, Martin Buchholz wrote:
>>>         hi Roger,
>>>
>>>         509 if (deadline <= 0) {
>>>         510 deadline = Long.MAX_VALUE;
>>>         511 }
>>>
>>>         This must be wrong.? Nanotime wraparound is normal in this
>>>         sort of code.
>>         ok, this reader didn't make that assumption
>>>
>>>         ---
>>>
>>>         We ought to be able to delegate the fiddling with nanos to
>>>         TimeUnit.timedWait.
>>>
>>>         Does it work to simply call
>>>         NANOSECONDS.timedWait(remainingNanos) ?
>>>         If not, is there a bug in TimeUnit.timedWait?
>>         That works except on Windows, that does not use wait().
>>
>>>
>>>         It's good to add a test for this.? I've tried hard in
>>>         similar tests to avoid sleep and to add variants where the
>>>         target thread is interrupted before and after starting to
>>>         wait.? Testing pre-interrupt is easy - the thread can
>>>         interrupt itself. BlockingQueueTest.testTimedPollWithOffer
>>>         is an example.
>>         I added a test, using the same logic as the existing tests
>>         for the Long.MAX_VALUE case
>>
>>         Thanks, Roger
>>
>>>
>>>
>>>
>>>
>>>         On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs
>>>         <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>>
>>>             Please review a fix for
>>>             Process.waitFor(Long.MAX_VALUE,MILLIS).
>>>             Catch wrap around in very large wait times and saturate
>>>             at Long.MAX_VALUE.
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>>>             <http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/>
>>>
>>>             Issue:
>>>             https://bugs.openjdk.java.net/browse/JDK-8208715
>>>             <https://bugs.openjdk.java.net/browse/JDK-8208715>
>>>
>>>             Thanks, Roger
>>>
>>>
>>
>>
>
>


From martinrb at google.com  Wed Aug 15 14:22:40 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 15 Aug 2018 07:22:40 -0700
Subject: RFR 8208715: Conversion of milliseconds to nanoseconds in
 UNIXProcess contains bug
In-Reply-To: <ec961fb4-547e-24ba-f705-5e50c3b89b76@Oracle.com>
References: <08333928-94ec-56b7-ddd2-dd5b52e27b80@Oracle.com>
 <CA+kOe09Lun_A+6PunRwSw_qRXuap-gdqL8j4gMifKVrvJ2izWw@mail.gmail.com>
 <9c126e95-ebfc-58f2-605c-5d94291a27e0@Oracle.com>
 <CA+kOe08bPadREsZ-bOirt7MoBhs=EWGDNgUzs2HCZkW+0Gye4g@mail.gmail.com>
 <3d45ffdf-3a84-7f1a-8bdd-e510b9291880@Oracle.com>
 <CA+kOe0_BEfQ0iWJUarUe5qhT7v5ZgYG11ik=7FNCjLW5wzmgag@mail.gmail.com>
 <ec961fb4-547e-24ba-f705-5e50c3b89b76@Oracle.com>
Message-ID: <CA+kOe098mJ6JMMPGbNOJ39BDRdatu7cidkD79jpKhOag5ebsiw@mail.gmail.com>

Your change is still approved, but ...

All tests are a little white-box in the sense that they are guided by where
bugs are likely to be found, which comes from experience with
implementations.  There is a collection of timed waiting APIs in the JDK
that throw InterruptedException.  It would be great if the entire test
matrix was covered: wait time 0, small positive wait times out, maximally
negative wait time, maximally positive wait time, interrupted before
waiting, interrupted while blocked in wait (Thread state not RUNNING), and
probably more.  We don't achieve full coverage anywhere, but it can be a
goal.

On Wed, Aug 15, 2018 at 7:06 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Martin,
>
> ok, as a reliable pattern I see that to avoid knowing details of the
> implementation.
> But the self interrupt seems redundant if the other is needed.
>
> Updated:
>   http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>
> Thanks, Roger
>
>
>
> On 8/14/2018 6:14 PM, Martin Buchholz wrote:
>
> Looks good to me ... but ...
>
> my intent was that the self-interrupt was added in __addition__ to
> interrupt by other thread, because there is often different code to handle
> pre-existing interrupt.  As with BlockingQueueTest.testTimedPollWithOffer.
>
>                 public void run() {
>                     Thread.currentThread().interrupt();
>                     try {
>                         boolean result = p.waitFor(Long.MAX_VALUE,
> TimeUnit.MILLISECONDS);
>                         fail("Should have thrown InterruptedException");
>                     } catch (InterruptedException success) {
>                     } catch (Throwable t) { unexpected(t); }
>
>                     try {
>                         aboutToWaitFor.countDown();
>                         boolean result = p.waitFor(Long.MAX_VALUE,
> TimeUnit.MILLISECONDS);
>                         fail("Should have thrown InterruptedException");
>                     } catch (InterruptedException success) {
>                     } catch (Throwable t) { unexpected(t); }
>
>
>
>
> On Tue, Aug 14, 2018 at 12:59 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> Updated with suggestions:
>>  http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/index.html
>>
>> On 8/14/2018 1:22 PM, Martin Buchholz wrote:
>>
>> Thanks, Roger.  I approve this version, although as always I have
>> comments.
>>
>>  520     private static native void waitForTimeoutInterruptibly(
>>  521         long handle, long timeout);
>>
>> The units being used should be obvious from the signature - rename
>> timeout to timeoutMillis.
>>
>> Done
>>
>> But even better is to push the support for nanos into the utility method,
>> so change this native method to accept a timeoutNanos.
>>
>> A bit far from the original issue and it might take a bit more time.
>>
>>
>> 2465             Thread.sleep(1000);
>>
>> I hate sleeps, and I would just delete this one - I don't think the test
>> relies on it (and if it did, one second is not long enough!).
>>
>> Done.  (And in the test case used for the copy/paste of the new test).
>>
>>
>> 2454                     try {
>> 2455                         aboutToWaitFor.countDown();
>> 2456                         boolean result = p.waitFor(Long.MAX_VALUE,
>> TimeUnit.MILLISECONDS);
>> 2457                         fail("waitFor() wasn't interrupted, its
>> return value was: " + result);
>> 2458                     } catch (InterruptedException success) {
>> 2459                     } catch (Throwable t) { unexpected(t); }
>>
>> It's easy to add a self-interrupt variant inside the run method
>>
>> Thread.currentThread().interrupt(); ...
>>
>> ok, and will run all the tests again.
>>
>> Thanks, Roger
>>
>>
>>
>> (TODO: Basic.java is in need of a re-write - mea culpa ...)
>>
>>
>>
>>
>>
>> On Tue, Aug 14, 2018 at 9:48 AM, Roger Riggs <Roger.Riggs at oracle.com>
>> wrote:
>>
>>> Hi Martin,
>>>
>>> I updated the webrev with the suggestions.
>>>
>>> On 8/14/2018 10:47 AM, Martin Buchholz wrote:
>>>
>>> hi Roger,
>>>
>>>  509         if (deadline <= 0) { 510             deadline = Long.MAX_VALUE; 511         }
>>>
>>>
>>> This must be wrong.  Nanotime wraparound is normal in this sort of code.
>>>
>>> ok, this reader didn't make that assumption
>>>
>>>
>>> ---
>>>
>>> We ought to be able to delegate the fiddling with nanos to
>>> TimeUnit.timedWait.
>>>
>>> Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
>>> If not, is there a bug in TimeUnit.timedWait?
>>>
>>> That works except on Windows, that does not use wait().
>>>
>>>
>>> It's good to add a test for this.  I've tried hard in similar tests to
>>> avoid sleep and to add variants where the target thread is interrupted
>>> before and after starting to wait.  Testing pre-interrupt is easy - the
>>> thread can interrupt itself.  BlockingQueueTest.testTimedPollWithOffer
>>> is an example.
>>>
>>> I added a test, using the same logic as the existing tests for the
>>> Long.MAX_VALUE case
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com>
>>> wrote:
>>>
>>>> Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>>>> Catch wrap around in very large wait times and saturate at
>>>> Long.MAX_VALUE.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8208715
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>
>>>
>>
>>
>
>

From mearvk at outlook.com  Wed Aug 15 15:20:20 2018
From: mearvk at outlook.com (mr rupplin)
Date: Wed, 15 Aug 2018 15:20:20 +0000
Subject: Removing the Barrier
Message-ID: <SN6PR07MB50223C7C713C0D062CD39787DA3F0@SN6PR07MB5022.namprd07.prod.outlook.com>

Can you explain how to remove the requirement for comments in the OpenJDK build in the Java source files?  It's really killing my schedule to have to reinsert comments by hand.

Thanks.

Max R.

Software Developer

From adam.farley at uk.ibm.com  Wed Aug 15 15:29:52 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 15 Aug 2018 16:29:52 +0100
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
Message-ID: <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.0055226C@notes.na.collabserv.com>

Hi Mandy, Hans,

Tried out the below (after removing my previous fix, the volatile 
compare), and it appears to solve the problem just fine. 

If I generate a webrev and get it attached to the bug, would one of you 
mind approving the change?

----------...at the end of getBundleImpl in jdk8  ------------
        keepAlive(loader);
        return bundle;
}

//To keep the argument ClassLoader alive.
private static void keepAlive(ClassLoader loaderone){
            //Do nothing.
}
----------------------

Best Regards

Adam Farley 

Hans Boehm <hboehm at google.com> wrote on 15/08/2018 06:44:08:

> From: Hans Boehm <hboehm at google.com>
> To: Mandy Chung <mandy.chung at oracle.com>
> Cc: adam.farley at uk.ibm.com, core-libs-dev <core-libs-
> dev at openjdk.java.net>, i18n-dev at openjdk.java.net
> Date: 15/08/2018 06:44
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix 
included)
> 
> FWIW, since there was agreement that empty static methods should 
> work in this context, that seems like the best option to me.
> 
> On Tue, Aug 14, 2018 at 4:54 PM mandy chung <mandy.chung at oracle.com> 
wrote:
> Thanks for the information.  Not sure what's the best option we can do
> in 8u.  I think it's acceptable to have a fix that works in the
> current context (like empty static method).
> 
> Thoughts?
> 
> Mandy
> 
> On 8/14/18 4:22 PM, Hans Boehm wrote:
> > I haven't looked at the details here, but comparing against a volatile 

> > is not in general a portable way to keep an object live. Like empty 
> > static methods, it may be fine in the current (OpenJDK) context.
> > 
> > Volatile loads have roach motel semantics and can be advanced past 
other 
> > operations. The comparison can be done early, too, keeping only the 
> > condition code. There is no guarantee the reference will still be 
around 
> > when you expect it.
> > 
> > I haven't come up with a great compiler-independent replacement for 
> > reachabilityFence.
> > 
> > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com 
> > <mailto:mandy.chung at oracle.com>> wrote:
> > 
> >     Hi Adam,
> > 
> >     Have you tried Peter's suggestion if an empty static method taking 
an
> >     Object parameter?  Does it work for you?
> > 
> >     Your proposed approach seems fine and I would suggest to put the
> >     check in a static keepAlive method that will make it explicitly.
> > 
> >     Mandy
> > 
> >     On 8/10/18 8:42 AM, Adam Farley8 wrote:
> >      > Hi All,
> >      >
> >      > This bug could be fixed by comparing the Class Loader with a 
blank
> >      > static volatile Object (defined outside the method scope) at 
the
> >      > end of the getBundleImpl class.
> >      >
> >      > E.g.
> >      >
> >      > -----------------------------------------
> >      > +1322
> >      >      /**
> >      >       * volatile reference object to guard the ClassLoader 
object
> >      >       * being garbage collected before getBundleImpl() method
> >     completes
> >      >       * the caching and retrieving of requested Resourcebundle 
object
> >      >       */
> >      >      private static volatile Object vo = new Object();
> >      >
> >      >
> >      > +1400
> >      > //Should never be true. Using the loader here prevents it being 
GC'd.
> >      >              if (loader == vo) throw new Error("Unexpected 
error.");
> >      > -----------------------------------------
> >      >
> >      > Will upload a webrev after debate.
> >      >
> >      > - Adam
> >      > Unless stated otherwise above:
> >      > IBM United Kingdom Limited - Registered in England and Wales 
with
> >     number
> >      > 741598.
> >      > Registered office: PO Box 41, North Harbour, Portsmouth,
> >     Hampshire PO6 3AU
> >      >
> > 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From adam.farley at uk.ibm.com  Wed Aug 15 15:45:03 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 15 Aug 2018 16:45:03 +0100
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
 <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
Message-ID: <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>

Hi Mandy, Hans,

Tried out the below (after removing my previous fix, the volatile 
compare), and it appears to solve the problem just fine. 

If I generate a webrev and get it attached to the bug, would one of you 
mind approving the change?

----------...at the end of getBundleImpl in jdk8  ------------
        keepAlive(loader);
        return bundle;
}

//To keep the argument ClassLoader alive.
private static void keepAlive(ClassLoader loaderone){
            //Do nothing.
}
----------------------

Best Regards

Adam Farley 

Hans Boehm <hboehm at google.com> wrote on 15/08/2018 06:44:08:

> From: Hans Boehm <hboehm at google.com>
> To: Mandy Chung <mandy.chung at oracle.com>
> Cc: adam.farley at uk.ibm.com, core-libs-dev <core-libs-
> dev at openjdk.java.net>, i18n-dev at openjdk.java.net
> Date: 15/08/2018 06:44
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix 
included)
> 
> FWIW, since there was agreement that empty static methods should 
> work in this context, that seems like the best option to me.
> 
> On Tue, Aug 14, 2018 at 4:54 PM mandy chung <mandy.chung at oracle.com> 
wrote:
> Thanks for the information.  Not sure what's the best option we can do
> in 8u.  I think it's acceptable to have a fix that works in the
> current context (like empty static method).
> 
> Thoughts?
> 
> Mandy
> 
> On 8/14/18 4:22 PM, Hans Boehm wrote:
> > I haven't looked at the details here, but comparing against a volatile 

> > is not in general a portable way to keep an object live. Like empty 
> > static methods, it may be fine in the current (OpenJDK) context.
> > 
> > Volatile loads have roach motel semantics and can be advanced past 
other 
> > operations. The comparison can be done early, too, keeping only the 
> > condition code. There is no guarantee the reference will still be 
around 
> > when you expect it.
> > 
> > I haven't come up with a great compiler-independent replacement for 
> > reachabilityFence.
> > 
> > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com 
> > <mailto:mandy.chung at oracle.com>> wrote:
> > 
> >     Hi Adam,
> > 
> >     Have you tried Peter's suggestion if an empty static method taking 
an
> >     Object parameter?  Does it work for you?
> > 
> >     Your proposed approach seems fine and I would suggest to put the
> >     check in a static keepAlive method that will make it explicitly.
> > 
> >     Mandy
> > 
> >     On 8/10/18 8:42 AM, Adam Farley8 wrote:
> >      > Hi All,
> >      >
> >      > This bug could be fixed by comparing the Class Loader with a 
blank
> >      > static volatile Object (defined outside the method scope) at 
the
> >      > end of the getBundleImpl class.
> >      >
> >      > E.g.
> >      >
> >      > -----------------------------------------
> >      > +1322
> >      >      /**
> >      >       * volatile reference object to guard the ClassLoader 
object
> >      >       * being garbage collected before getBundleImpl() method
> >     completes
> >      >       * the caching and retrieving of requested Resourcebundle 
object
> >      >       */
> >      >      private static volatile Object vo = new Object();
> >      >
> >      >
> >      > +1400
> >      > //Should never be true. Using the loader here prevents it being 
GC'd.
> >      >              if (loader == vo) throw new Error("Unexpected 
error.");
> >      > -----------------------------------------
> >      >
> >      > Will upload a webrev after debate.
> >      >
> >      > - Adam
> >      > Unless stated otherwise above:
> >      > IBM United Kingdom Limited - Registered in England and Wales 
with
> >     number
> >      > 741598.
> >      > Registered office: PO Box 41, North Harbour, Portsmouth,
> >     Hampshire PO6 3AU
> >      >
> > 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From dalibor.topic at oracle.com  Wed Aug 15 15:49:53 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 15 Aug 2018 17:49:53 +0200
Subject: Core Type Compilation Issues
In-Reply-To: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <e6f69d0c-08ad-643d-d07c-023ac135b4ce@oracle.com>



On 06.08.2018 20:21, mr rupplin wrote:
> Three problems that I run into when running the 'make jdk' after minor work on the System.java class for JNI and custom JDK:
> 
> java/lang/memory/GroupListener.java:111:
> 
> Can we get explanations for each of these? 

No.

There is no java.lang.memory in OpenJDK. So it looks as if you are not 
using OpenJDK, you're using something else.

Ask whoever gave you what you're using for support. We can't help you 
fix it.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From mandy.chung at oracle.com  Wed Aug 15 16:49:51 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 15 Aug 2018 09:49:51 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
 <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
 <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>
Message-ID: <e9e19390-a0ca-9bf8-24b7-3b033a676680@oracle.com>

Hi Adam,

This fix is JDK 8u only and so you will need to request for 8u approval.

The proposed empty static method is fine with me.  Please fix the format 
and indentation before you post the review.

Since this patch is small, you can inline the diff in the RFR mail.
I can review it when you send the review request out.

Mandy
[1] http://openjdk.java.net/projects/jdk8u/approval-template.html

On 8/15/18 8:45 AM, Adam Farley8 wrote:
> Hi Mandy, Hans,
> 
> Tried out the below (after removing my previous fix, the volatile 
> compare), and it appears to solve the problem just fine.
> 
> If I generate a webrev and get it attached to the bug, would one of you 
> mind approving the change?
> 
> ----------...at the end of getBundleImpl in jdk8 ?------------
>  ? ? keepAlive(loader);
>  ? ? return bundle;
> }
> 
> //To keep the argument ClassLoader alive.
> private static void keepAlive(ClassLoader loaderone){
>  ? ? ? ? //Do nothing.
> }
> ----------------------
> 
> Best Regards
> 
> Adam Farley
> 
> Hans Boehm <hboehm at google.com> wrote on 15/08/2018 06:44:08:
> 
>> From: Hans Boehm <hboehm at google.com>
>> To: Mandy Chung <mandy.chung at oracle.com>
>> Cc: adam.farley at uk.ibm.com,  core-libs-dev <core-libs-
>> dev at openjdk.java.net>, i18n-dev at openjdk.java.net
>> Date: 15/08/2018 06:44
>> Subject: Re: RFR 8209184: JDK8  ResourceBundle vulnerable to GC (fix included)
>> 
>> FWIW, since there was agreement that empty static methods should 
>> work in this context, that seems like the best option to me.
>> 
>> On Tue, Aug 14, 2018 at 4:54 PM mandy chung <mandy.chung at oracle.com>  wrote:
>> Thanks for the information. Not sure what's the best option we can do
>> in 8u.? I think it's acceptable to have a fix that works in the
>> current context (like empty static method).
>> 
>> Thoughts?
>> 
>> Mandy
>> 
>> On 8/14/18 4:22 PM, Hans Boehm wrote:
>> > I haven't looked at the details here, but comparing against a  volatile
>> > is not in general a portable way to keep an object live. Like  empty
>> > static methods, it may be fine in the current (OpenJDK) context.
>> > 
>> > Volatile loads have roach motel semantics and can be advanced  past other
>> > operations. The comparison can be done early, too, keeping only  the
>> > condition code. There is no guarantee the reference will still  be around
>> > when you expect it.
>> > 
>> > I haven't come up with a great compiler-independent replacement  for
>> > reachabilityFence.
>> > 
>> > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com
>> > <mailto:mandy.chung at oracle.com>> wrote:
>> > 
>> >? ? ?Hi Adam,
>> > 
>> >? ? ?Have you tried Peter's suggestion if an empty  static method taking an
>> >? ? ?Object parameter?? Does it work for you?
>> > 
>> >? ? ?Your proposed approach seems fine and I would  suggest to put the
>> >? ? ?check in a static keepAlive method that will  make it explicitly.
>> > 
>> >? ? ?Mandy
>> > 
>> >? ? ?On 8/10/18 8:42 AM, Adam Farley8 wrote:
>> >? ? ? > Hi All,
>> >? ? ? >
>> >? ? ? > This bug could be fixed by comparing  the Class Loader with a blank
>> >? ? ? > static volatile Object (defined outside  the method scope) at the
>> >? ? ? > end of the getBundleImpl class.
>> >? ? ? >
>> >? ? ? > E.g.
>> >? ? ? >
>> >? ? ? > -----------------------------------------
>> >? ? ? > +1322
>> >? ? ? >? ? ? /**
>> >? ? ? >? ? ? ?* volatile  reference object to guard the ClassLoader object
>> >? ? ? >? ? ? ?* being garbage  collected before getBundleImpl() method
>> >? ? ?completes
>> >? ? ? >? ? ? ?* the caching  and retrieving of requested Resourcebundle object
>> >? ? ? >? ? ? ?*/
>> >? ? ? >? ? ? private static volatile  Object vo = new Object();
>> >? ? ? >
>> >? ? ? >
>> >? ? ? > +1400
>> >? ? ? > //Should never be true. Using the loader  here prevents it being GC'd.
>> >? ? ? >            ? if (loader == vo) throw new Error("Unexpected error.");
>> >? ? ? > -----------------------------------------
>> >? ? ? >
>> >? ? ? > Will upload a webrev after debate.
>> >? ? ? >
>> >? ? ? > - Adam
>> >? ? ? > Unless stated otherwise above:
>> >? ? ? > IBM United Kingdom Limited - Registered  in England and Wales with
>> >? ? ?number
>> >? ? ? > 741598.
>> >? ? ? > Registered office: PO Box 41, North  Harbour, Portsmouth,
>> >? ? ?Hampshire PO6 3AU
>> >? ? ? >
>> > 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From peter.levart at gmail.com  Wed Aug 15 17:16:34 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 15 Aug 2018 19:16:34 +0200
Subject: Core Type Compilation Issues
In-Reply-To: <e6f69d0c-08ad-643d-d07c-023ac135b4ce@oracle.com>
References: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
 <e6f69d0c-08ad-643d-d07c-023ac135b4ce@oracle.com>
Message-ID: <03ae91eb-04a4-2b40-7b1b-03f5f2e2d16f@gmail.com>



On 08/15/2018 05:49 PM, dalibor topic wrote:
>
>
> On 06.08.2018 20:21, mr rupplin wrote:
>> Three problems that I run into when running the 'make jdk' after 
>> minor work on the System.java class for JNI and custom JDK:
>>
>> java/lang/memory/GroupListener.java:111:
>>
>> Can we get explanations for each of these? 
>
> No.
>
> There is no java.lang.memory in OpenJDK. So it looks as if you are not 
> using OpenJDK, you're using something else.

Or Mr. Rupplin is adding class GroupListener to OpenJDK, thus creating 
new package java.lang.memory.

In that case I would suggest adding the class to some existent jdk 
internal package of java.base module below the jdk.internal. package 
hierarchy (java.lang. hierarchy is reserved). But as David Holmes 
already suggested, if this class depends on java.rmi classes, it may not 
be located in java.base module if it wants to access these classes 
directly from compiled code. OTOH it must be located in java.base module 
if it wants to be used from java.lang.System class (which I suspect Mr. 
Rupplin is doing from his message mentioning work on System.java class). 
It is possible to access java.rmi classes from java.base module using 
reflection though. Or better yet, using ServiceLoader mechanism.

So I would suggest Mr. Rupplin to:
- define a jdk internal service interface for the minimal functionality 
needed from java.rmi module in the java.base module.
- implement this interface by a concealed class in the java.rmi module 
and provide the service by adding "provides" directive to 
module-info.java of the java.rmi module
- declare that java.base module "uses" the service (in the 
module-info.java of the java.base module)
- code the logic in java.lang.System or helper class by loading the 
service using ServiceLoader API - the logic should be prepared to not 
find any such service since java.rmi module may not be present at runtime
- service interface and any additional utility classes such as 
GroupListener in java.base module should be put into existent (or new) 
jdk internal package(s) below the jdk.internal. package hierarchy.
- the package containintg the service interface should be exported to 
java.rmi module only that provides the implementation of the service

Hope this helps,

Regards, Peter


From peter.levart at gmail.com  Wed Aug 15 17:26:32 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 15 Aug 2018 19:26:32 +0200
Subject: Core Type Compilation Issues
In-Reply-To: <03ae91eb-04a4-2b40-7b1b-03f5f2e2d16f@gmail.com>
References: <SN6PR07MB50228660CE2E9750004EB1B7DA200@SN6PR07MB5022.namprd07.prod.outlook.com>
 <e6f69d0c-08ad-643d-d07c-023ac135b4ce@oracle.com>
 <03ae91eb-04a4-2b40-7b1b-03f5f2e2d16f@gmail.com>
Message-ID: <78d885a8-ad41-3ab7-7ecf-53543af0843d@gmail.com>



On 08/15/2018 07:16 PM, Peter Levart wrote:
>
>
> On 08/15/2018 05:49 PM, dalibor topic wrote:
>>
>>
>> On 06.08.2018 20:21, mr rupplin wrote:
>>> Three problems that I run into when running the 'make jdk' after 
>>> minor work on the System.java class for JNI and custom JDK:
>>>
>>> java/lang/memory/GroupListener.java:111:
>>>
>>> Can we get explanations for each of these? 
>>
>> No.
>>
>> There is no java.lang.memory in OpenJDK. So it looks as if you are 
>> not using OpenJDK, you're using something else.
>
> Or Mr. Rupplin is adding class GroupListener to OpenJDK, thus creating 
> new package java.lang.memory.
>
> In that case I would suggest adding the class to some existent jdk 
> internal package of java.base module below the jdk.internal. package 
> hierarchy (java.lang. hierarchy is reserved). But as David Holmes 
> already suggested, if this class depends on java.rmi classes, it may 
> not be located in java.base module if it wants to access these classes 
> directly from compiled code. OTOH it must be located in java.base 
> module if it wants to be used from java.lang.System class (which I 
> suspect Mr. Rupplin is doing from his message mentioning work on 
> System.java class). It is possible to access java.rmi classes from 
> java.base module using reflection though. Or better yet, using 
> ServiceLoader mechanism.
>
> So I would suggest Mr. Rupplin to:
> - define a jdk internal service interface for the minimal 
> functionality needed from java.rmi module in the java.base module.
> - implement this interface by a concealed class in the java.rmi module 
> and provide the service by adding "provides" directive to 
> module-info.java of the java.rmi module
> - declare that java.base module "uses" the service (in the 
> module-info.java of the java.base module)
> - code the logic in java.lang.System or helper class by loading the 
> service using ServiceLoader API - the logic should be prepared to not 
> find any such service since java.rmi module may not be present at runtime
> - service interface and any additional utility classes such as 
> GroupListener in java.base module should be put into existent (or new) 
> jdk internal package(s) below the jdk.internal. package hierarchy.
> - the package containintg the service interface should be exported to 
> java.rmi module only that provides the implementation of the service
>
> Hope this helps,
>
> Regards, Peter
>

The big question for Mr. Rupplin is why does he want to put the logic 
that uses java.rmi module into java.lang.System class (or API). Wouldn't 
such logic (or API) belong to java.rmi module and shouldn't Mr. Rupplin 
extend its API instead? Some explanation about the intentions would help 
suggest the right approach.

Peter


From joe.darcy at oracle.com  Wed Aug 15 17:42:43 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 15 Aug 2018 10:42:43 -0700
Subject: JDK 12 RFR of 5075463 : (enum) Serialized Form javadoc for
 java.lang.Enum is misleading
In-Reply-To: <7ba5d03c-d564-5002-8c98-a64f7642bea6@oracle.com>
References: <71ba86dc-07de-89dd-2733-8a68d9666b45@oracle.com>
 <F9E60CD3-80EC-437A-AA39-EEFE59450F8B@oracle.com>
 <7ba5d03c-d564-5002-8c98-a64f7642bea6@oracle.com>
Message-ID: <ee350986-6e88-90d9-93ed-00a4c164ea75@oracle.com>

Hi Roger,

Filed JDK-8209542: "Serialization discussion of enum types should 
mention java.lang.Enum."

Thanks for the review,

-Joe


On 8/15/2018 6:20 AM, Roger Riggs wrote:
> Hi Joe,
>
> This change looks fine as the spec for serializing Enum's is in OIS 
> and OOS.
>
> However, the spec for serializing Enum's in ObjectInputStream and 
> ObjectOutputStream is incomplete.
> It does not mention that the class of the Enum is written to the 
> stream before the enum name.
> Please file an issue for that.
>
> Regards, Roger
>
>
> On 8/15/18 7:27 AM, Lance Andersen wrote:
>> Hi Joe,
>>
>> Added myself as a reviewer to the CSR and the change looks fine
>>
>> On Aug 14, 2018, at 11:59 PM, joe darcy <joe.darcy at oracle.com> wrote:
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8209524
>>
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>
>>
>


From peter.levart at gmail.com  Wed Aug 15 17:43:46 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 15 Aug 2018 19:43:46 +0200
Subject: Removing the Barrier
In-Reply-To: <SN6PR07MB50223C7C713C0D062CD39787DA3F0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50223C7C713C0D062CD39787DA3F0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <1a1ebf78-c3ef-533c-42a8-088062ec1a73@gmail.com>

The javadoc comments in public API are a requirement in OpenJDK and can 
not be removed. This is the OpenJDK project policy. If you want to 
extend OpenJDK you have to add the comments. And not only comments. New 
public API may be added to OpenJDK only after passing the special 
process called CSR:

https://wiki.openjdk.java.net/display/csr/Main

So if your schedule doesn't allow you to add comments, I would not 
venture into adding new public API to OpenJDK as it is much more work 
than just adding comments...

Regards, Peter

On 08/15/2018 05:20 PM, mr rupplin wrote:
> Can you explain how to remove the requirement for comments in the OpenJDK build in the Java source files?  It's really killing my schedule to have to reinsert comments by hand.
>
> Thanks.
>
> Max R.
>
> Software Developer


From ecki at zusammenkunft.net  Wed Aug 15 18:39:21 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 15 Aug 2018 18:39:21 +0000
Subject: Removing the Barrier
In-Reply-To: <SN6PR07MB50223C7C713C0D062CD39787DA3F0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50223C7C713C0D062CD39787DA3F0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <DB7PR08MB3307D70544E04FFA955D906DFF3F0@DB7PR08MB3307.eurprd08.prod.outlook.com>

You can remove all comments you like. If you do not distribute the resulting binaries you do not need to provide the changes/source you made (that?s a legal requirement from the GPL license). If you do need to provide source (because you distribute binaries) then you have to retain at least all copyright messages and license headers.

This assumes the comments have no technical function, this is true for normal code but not formsome parts like for example tests where execution parameters can be found in the comments. I am not sure about other locations where code generation references comments is used (but simply speaking if a comment looks unstructured it probably has no function)

Also keep in mind that comments are visible if you generate Javadoc or need to use src.zip (think IDEs)

Having said all that, that kind of shredded code does not get you very far, it will certainly not allow to contribute changes back to OpenJDK projects. Besides changing all line numbers (by removing comments from Java classes) also makes interpreting stacktraces harder.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: -1060516144m Auftrag von
Gesendet: Mittwoch, August 15, 2018 7:35 PM
An: core-libs-dev at openjdk.java.net
Betreff: Removing the Barrier

Can you explain how to remove the requirement for comments in the OpenJDK build in the Java source files? It's really killing my schedule to have to reinsert comments by hand.

Thanks.

Max R.

Software Developer

From igor.ignatyev at oracle.com  Wed Aug 15 21:00:27 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 15 Aug 2018 14:00:27 -0700
Subject: RFR(XXS) : 8209549 : remove VMPropsExt from TEST.ROOT
Message-ID: <3B4B5DC5-36CA-4348-9C5D-FE34A5BEA339@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html
> 2 lines changed: 0 ins; 0 del; 2 mod;

Hi all,

could you please review this tiny patch which removes unused (and actually non-existed) file from requires.extraPropDefns and simplifies paths in requires.extraPropDefns and requires.extraPropDefns.bootlibs?

webrev: http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html
testing: jdk/tier1

Thanks,
-- Igor

From mandy.chung at oracle.com  Wed Aug 15 21:46:24 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 15 Aug 2018 14:46:24 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
Message-ID: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>

ExceptionInInitializerError(Throwable cause) sets the detail message to 
null.  It'd be helpful to include a detail message rather than null
as in Throwable(Throwable cause) that constructs a new throwable
with a default message cause==null ? null : cause.toString().

This would help troubleshooting of writing new bootstrap methods
where VM currently asserts non-null linkage error message [1] where
there are other solutions such as constructing the message in
the VM or removing the assert.

This patch proposes to change ExceptionInInitializerError(Throwable cause)
to default the detail message to cause.toString() if cause is not null.
It's an incompatibility change; for example existing code that expects
a null message will now see a detail message.  But the compatibility
risk should be low as EIIE should be fatal.

This also proposes to add new LinkageError(Throwable cause) constructor
to retrofit the exception chaining mechanism and that allows to clean up
the current ExceptionInInitializerError implementation.

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00

I will create a CSR.

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8208172

From peter.levart at gmail.com  Wed Aug 15 22:20:01 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 16 Aug 2018 00:20:01 +0200
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
Message-ID: <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>

Hi Mandy,

Just a question. Why does "private Throwable exception" field in 
ExceptionInInitializerError exist? Was it there before there was a 
"cause" in Throwable and later still remained there because of 
serialization format? Would it be possible to "simulate" its effect for 
serialization using "serialPersistentFields" and 
ObjectOutputStream.PutField?

The main challegne, I think, would be the deserialization of an old 
ExceptionInInitializerError.exception into new Throwable.cause in case 
the stream did not have Throwable.cause (which is the case for old 
ExceptionInInitializerError(s))

Ragards, Peter

On 08/15/2018 11:46 PM, mandy chung wrote:
> ExceptionInInitializerError(Throwable cause) sets the detail message 
> to null.? It'd be helpful to include a detail message rather than null
> as in Throwable(Throwable cause) that constructs a new throwable
> with a default message cause==null ? null : cause.toString().
>
> This would help troubleshooting of writing new bootstrap methods
> where VM currently asserts non-null linkage error message [1] where
> there are other solutions such as constructing the message in
> the VM or removing the assert.
>
> This patch proposes to change ExceptionInInitializerError(Throwable 
> cause)
> to default the detail message to cause.toString() if cause is not null.
> It's an incompatibility change; for example existing code that expects
> a null message will now see a detail message.? But the compatibility
> risk should be low as EIIE should be fatal.
>
> This also proposes to add new LinkageError(Throwable cause) constructor
> to retrofit the exception chaining mechanism and that allows to clean up
> the current ExceptionInInitializerError implementation.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00
>
> I will create a CSR.
>
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8208172


From igor.ignatyev at oracle.com  Wed Aug 15 22:56:58 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 15 Aug 2018 15:56:58 -0700
Subject: RFR(XXS) : 8209386 : [error-prone] StreamResourceLeak in
 jdk.internal.ed module
In-Reply-To: <3AB5CED9-A9BE-4686-AFAE-05A6E5D10CE6@oracle.com>
References: <3AB5CED9-A9BE-4686-AFAE-05A6E5D10CE6@oracle.com>
Message-ID: <3960FCE6-A76B-43FD-B2FA-E17CB1DE4F76@oracle.com>

ping?

-- Igor

> On Aug 10, 2018, at 1:44 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
>> 4 lines changed: 1 ins; 0 del; 3 mod;
> 
> Hi all,
> 
> could you please review this small fix for the error detected in jdk.internal.ed by error-prone?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209386
> 
> Thanks,
> -- Igor


From mandy.chung at oracle.com  Thu Aug 16 00:10:22 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 15 Aug 2018 17:10:22 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
Message-ID: <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>



On 8/15/18 3:20 PM, Peter Levart wrote:
> Hi Mandy,
> 
> Just a question. Why does "private Throwable exception" field in 
> ExceptionInInitializerError exist? Was it there before there was a 
> "cause" in Throwable and later still remained there because of 
> serialization format? Would it be possible to "simulate" its effect for 
> serialization using "serialPersistentFields" and 
> ObjectOutputStream.PutField?

Thanks for asking.  I meant to mention this and it'd be nice to
follow up this in a separate issue.

The private exception field exists since 1.1 and kept there for
serialization.  getException in existing releases returns the
exception field.  I can't think of any way to remove the exception
field in JDK n to deserialize it with older JDK x unless JDK x was
changed to write the exception field with the cause or getException
to return cause.

I think we should remove the ExceptionInInitializerError::getCause
method and have getException to return getCause().  I think the
simplest is to keep the exception field and make sure it's set
with the cause. Existing version of EIIE always has null cause.
readObject will set the cause to be same as exception.  There may
be other options.

> The main challegne, I think, would be the deserialization of an old 
> ExceptionInInitializerError.exception into new Throwable.cause in case 
> the stream did not have Throwable.cause (which is the case for old 
> ExceptionInInitializerError(s))

Deserializing from an older EIIE to a newer EIIE is feasible.  I was
thinking to separate it as a different issue.

Mandy

From mandy.chung at oracle.com  Thu Aug 16 00:48:45 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 15 Aug 2018 17:48:45 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
Message-ID: <78df830b-2ef7-5f33-1a6d-d2cc757d2cd7@oracle.com>



On 8/15/18 5:10 PM, mandy chung wrote:
> 
> I think we should remove the ExceptionInInitializerError::getCause
> method and have getException to return getCause().? I think the
> simplest is to keep the exception field and make sure it's set
> with the cause. Existing version of EIIE always has null cause.
> readObject will set the cause to be same as exception.? There may
> be other options.

I prototype it:
    http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.01/

I manually verified it reading/writing with new and old version.
I will have to add the interop test case and possibly add a
package-private method to set Throwable::cause (rather than
making the field package-private).  Will update you.

Mandy

From david.holmes at oracle.com  Thu Aug 16 06:00:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Aug 2018 16:00:10 +1000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
Message-ID: <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>

Hi Mandy,

Not a review - sorry :)

On 16/08/2018 7:46 AM, mandy chung wrote:
> ExceptionInInitializerError(Throwable cause) sets the detail message to 
> null.? It'd be helpful to include a detail message rather than null
> as in Throwable(Throwable cause) that constructs a new throwable
> with a default message cause==null ? null : cause.toString().
> 
> This would help troubleshooting of writing new bootstrap methods
> where VM currently asserts non-null linkage error message [1] where
> there are other solutions such as constructing the message in
> the VM or removing the assert.

I think that's just a bug in the VM code making inappropriate 
assumptions! There shouldn't have to be a detail message, especially in 
a wrapping exception like ExceptionInInitializerError! It only gets 
thrown because some other exception was thrown, there's really no more 
detail for the EIIE itself. Promoting the cause's detail message to be 
the detail message of the EIIE just seems wrong to me.

Did this come about through the new code that saves the original cause 
of the EIIE so that it can be reported when the subsequent 
NoClassDefFoundError is thrown due to the class being in the erroneous 
state? (I don't recall if that actually got pushed.)

David

> 
> This patch proposes to change ExceptionInInitializerError(Throwable cause)
> to default the detail message to cause.toString() if cause is not null.
> It's an incompatibility change; for example existing code that expects
> a null message will now see a detail message.? But the compatibility
> risk should be low as EIIE should be fatal.
> 
> This also proposes to add new LinkageError(Throwable cause) constructor
> to retrofit the exception chaining mechanism and that allows to clean up
> the current ExceptionInInitializerError implementation.
> 
> Webrev:
>  ? http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00
> 
> I will create a CSR.
> 
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8208172

From david.holmes at oracle.com  Thu Aug 16 06:10:35 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Aug 2018 16:10:35 +1000
Subject: RFR(XXS) : 8209549 : remove VMPropsExt from TEST.ROOT
In-Reply-To: <3B4B5DC5-36CA-4348-9C5D-FE34A5BEA339@oracle.com>
References: <3B4B5DC5-36CA-4348-9C5D-FE34A5BEA339@oracle.com>
Message-ID: <ccd9d2a2-247d-9f3e-e5d4-8b4f0c8e7058@oracle.com>

Looks fine.

Thanks,
David

On 16/08/2018 7:00 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html
>> 2 lines changed: 0 ins; 0 del; 2 mod;
> 
> Hi all,
> 
> could you please review this tiny patch which removes unused (and actually non-existed) file from requires.extraPropDefns and simplifies paths in requires.extraPropDefns and requires.extraPropDefns.bootlibs?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html
> testing: jdk/tier1
> 
> Thanks,
> -- Igor
> 

From jai.forums2013 at gmail.com  Thu Aug 16 08:38:30 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 16 Aug 2018 14:08:30 +0530
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
 <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
 <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>
Message-ID: <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>

Hi Ivan,

On 15/08/18 4:27 PM, Jaikiran Pai wrote:
> Hi Ivan,
>
>
> On 15/08/18 1:20 PM, Ivan Gerasimov wrote:
>> Hi Jaikiran!
>>
>> The first part (the documentation clarification) was requested some
>> time ago [1], so it may be eventually fixed.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7033681
> Thank you for pointing to that one. I hadn't found it during my search
> before sending this mail.

Is this JIRA/change, something that I can contribute? If so, what would
be the typical process for that? I have signed and approved OCA, but I
don't know what's involved in submitting changes which involve javadoc
changes - does this need CSR and will that CSR have to be filed after I
submit the initial draft of the changed javadoc?

-Jaikiran


From adam.farley at uk.ibm.com  Thu Aug 16 09:16:21 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Thu, 16 Aug 2018 10:16:21 +0100
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <e9e19390-a0ca-9bf8-24b7-3b033a676680@oracle.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
 <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
 <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>
 <e9e19390-a0ca-9bf8-24b7-3b033a676680@oracle.com>
Message-ID: <OFE236AB4F.C720ABBD-ON002582EB.0030A93D-802582EB.0032F109@notes.na.collabserv.com>

Hi Mandy,

I request that you review this for 8u.

------------------------------------------------------
@@ -1398,10 +1398,18 @@
             bundle = baseBundle;
         }

+        keepAlive(loader);
         return bundle;
     }

     /**
+     * Keeps the argument ClassLoader alive.
+     */
+    private static void keepAlive(ClassLoader loaderone){
+        //Do nothing.
+    }
+
+    /**
      * Checks if the given <code>List</code> is not null, not empty,
      * not having null in its elements.
      */
------------------------------------------------------


Best Regards

Adam Farley 


mandy chung <mandy.chung at oracle.com> wrote on 15/08/2018 17:49:51:

> From: mandy chung <mandy.chung at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Hans Boehm 
<hboehm at google.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, 
i18n-dev at openjdk.java.net
> Date: 15/08/2018 17:50
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix 
included)
> 
> Hi Adam,
> 
> This fix is JDK 8u only and so you will need to request for 8u approval.
> 
> The proposed empty static method is fine with me.  Please fix the format 

> and indentation before you post the review.
> 
> Since this patch is small, you can inline the diff in the RFR mail.
> I can review it when you send the review request out.
> 
> Mandy
> [1] INVALID URI REMOVED
> 
u=http-3A__openjdk.java.net_projects_jdk8u_approval-2Dtemplate.html&d=DwID-
> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=LNli6mMzg3GKad9dsE3XbXBnzTk9woUBJ7J4LmWSCoM&s=7qqktTwgCMn4ZPhTnzh9Dfla2kn9iTtZxT47FUZ6otQ&e=
> 
> On 8/15/18 8:45 AM, Adam Farley8 wrote:
> > Hi Mandy, Hans,
> > 
> > Tried out the below (after removing my previous fix, the volatile 
> > compare), and it appears to solve the problem just fine.
> > 
> > If I generate a webrev and get it attached to the bug, would one of 
you 
> > mind approving the change?
> > 
> > ----------...at the end of getBundleImpl in jdk8  ------------
> >      keepAlive(loader);
> >      return bundle;
> > }
> > 
> > //To keep the argument ClassLoader alive.
> > private static void keepAlive(ClassLoader loaderone){
> >          //Do nothing.
> > }
> > ----------------------
> > 
> > Best Regards
> > 
> > Adam Farley
> > 
> > Hans Boehm <hboehm at google.com> wrote on 15/08/2018 06:44:08:
> > 
> >> From: Hans Boehm <hboehm at google.com>
> >> To: Mandy Chung <mandy.chung at oracle.com>
> >> Cc: adam.farley at uk.ibm.com,  core-libs-dev <core-libs-
> >> dev at openjdk.java.net>, i18n-dev at openjdk.java.net
> >> Date: 15/08/2018 06:44
> >> Subject: Re: RFR 8209184: JDK8  ResourceBundle vulnerable to GC 
> (fix included)
> >> 
> >> FWIW, since there was agreement that empty static methods should 
> >> work in this context, that seems like the best option to me.
> >> 
> >> On Tue, Aug 14, 2018 at 4:54 PM mandy chung 
> <mandy.chung at oracle.com>  wrote:
> >> Thanks for the information. Not sure what's the best option we can do
> >> in 8u.  I think it's acceptable to have a fix that works in the
> >> current context (like empty static method).
> >> 
> >> Thoughts?
> >> 
> >> Mandy
> >> 
> >> On 8/14/18 4:22 PM, Hans Boehm wrote:
> >> > I haven't looked at the details here, but comparing against a 
volatile
> >> > is not in general a portable way to keep an object live. Like empty
> >> > static methods, it may be fine in the current (OpenJDK) context.
> >> > 
> >> > Volatile loads have roach motel semantics and can be advanced  past 
other
> >> > operations. The comparison can be done early, too, keeping only the
> >> > condition code. There is no guarantee the reference will still be 
around
> >> > when you expect it.
> >> > 
> >> > I haven't come up with a great compiler-independent replacement for
> >> > reachabilityFence.
> >> > 
> >> > On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mandy.chung at oracle.com
> >> > <mailto:mandy.chung at oracle.com>> wrote:
> >> > 
> >> >     Hi Adam,
> >> > 
> >> >     Have you tried Peter's suggestion if an empty  static 
> method taking an
> >> >     Object parameter?  Does it work for you?
> >> > 
> >> >     Your proposed approach seems fine and I would  suggest to put 
the
> >> >     check in a static keepAlive method that will  make it 
explicitly.
> >> > 
> >> >     Mandy
> >> > 
> >> >     On 8/10/18 8:42 AM, Adam Farley8 wrote:
> >> >      > Hi All,
> >> >      >
> >> >      > This bug could be fixed by comparing  the Class Loader 
> with a blank
> >> >      > static volatile Object (defined outside  the method scope) 
at the
> >> >      > end of the getBundleImpl class.
> >> >      >
> >> >      > E.g.
> >> >      >
> >> >      > -----------------------------------------
> >> >      > +1322
> >> >      >      /**
> >> >      >       * volatile  reference object to guard the ClassLoader 
object
> >> >      >       * being garbage  collected before getBundleImpl() 
method
> >> >     completes
> >> >      >       * the caching  and retrieving of requested 
> Resourcebundle object
> >> >      >       */
> >> >      >      private static volatile  Object vo = new Object();
> >> >      >
> >> >      >
> >> >      > +1400
> >> >      > //Should never be true. Using the loader  here prevents 
> it being GC'd.
> >> >      >              if (loader == vo) throw new Error
> ("Unexpected error.");
> >> >      > -----------------------------------------
> >> >      >
> >> >      > Will upload a webrev after debate.
> >> >      >
> >> >      > - Adam
> >> >      > Unless stated otherwise above:
> >> >      > IBM United Kingdom Limited - Registered  in England and 
Wales with
> >> >     number
> >> >      > 741598.
> >> >      > Registered office: PO Box 41, North  Harbour, Portsmouth,
> >> >     Hampshire PO6 3AU
> >> >      >
> >> > 
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with 
number 
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From roger.riggs at oracle.com  Thu Aug 16 13:16:56 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 16 Aug 2018 09:16:56 -0400
Subject: RFR(XXS) : 8209386 : [error-prone] StreamResourceLeak in
 jdk.internal.ed module
In-Reply-To: <3AB5CED9-A9BE-4686-AFAE-05A6E5D10CE6@oracle.com>
References: <3AB5CED9-A9BE-4686-AFAE-05A6E5D10CE6@oracle.com>
Message-ID: <4194848f-a9d3-f4d9-2aa9-04b8cc2e5ff3@oracle.com>

Hi Igor,

Looks fine.

Thanks for the fix,? Roger

On 8/10/18 4:44 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
>> 4 lines changed: 1 ins; 0 del; 3 mod;
> Hi all,
>
> could you please review this small fix for the error detected in jdk.internal.ed by error-prone?
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209386
>
> Thanks,
> -- Igor


From roger.riggs at oracle.com  Thu Aug 16 13:34:27 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 16 Aug 2018 09:34:27 -0400
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
 <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
 <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>
 <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>
Message-ID: <3c8f3a68-566e-2b74-740d-5f7ae70ab10a@oracle.com>

Hi Jaikiran,

Improving the documentation of the current behavior would be a good 
contribution
and first step.? It will need a CSR since it needs to be checked that it 
accurately
describes the behavior but that will be pretty straightforward once the 
change is reviewed.

Note that Collection.remove("b") is following its specified behavior 
that is based on iterating
over the contents of the Collection. Only if the value is not found, 
will it attempt to remove
and get the exception.

Regards, Roger



On 8/16/18 4:38 AM, Jaikiran Pai wrote:
> Hi Ivan,
>
> On 15/08/18 4:27 PM, Jaikiran Pai wrote:
>> Hi Ivan,
>>
>>
>> On 15/08/18 1:20 PM, Ivan Gerasimov wrote:
>>> Hi Jaikiran!
>>>
>>> The first part (the documentation clarification) was requested some
>>> time ago [1], so it may be eventually fixed.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-7033681
>> Thank you for pointing to that one. I hadn't found it during my search
>> before sending this mail.
> Is this JIRA/change, something that I can contribute? If so, what would
> be the typical process for that? I have signed and approved OCA, but I
> don't know what's involved in submitting changes which involve javadoc
> changes - does this need CSR and will that CSR have to be filed after I
> submit the initial draft of the changed javadoc?
>
> -Jaikiran
>


From mandy.chung at oracle.com  Thu Aug 16 15:18:44 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 16 Aug 2018 08:18:44 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
Message-ID: <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>



On 8/15/18 11:00 PM, David Holmes wrote:
> Hi Mandy,
> 
> Not a review - sorry :)
> 
> On 16/08/2018 7:46 AM, mandy chung wrote:
>> ExceptionInInitializerError(Throwable cause) sets the detail message 
>> to null.? It'd be helpful to include a detail message rather than null
>> as in Throwable(Throwable cause) that constructs a new throwable
>> with a default message cause==null ? null : cause.toString().
>>
>> This would help troubleshooting of writing new bootstrap methods
>> where VM currently asserts non-null linkage error message [1] where
>> there are other solutions such as constructing the message in
>> the VM or removing the assert.
> 
> I think that's just a bug in the VM code making inappropriate 
> assumptions! There shouldn't have to be a detail message, especially in 
> a wrapping exception like ExceptionInInitializerError! It only gets 
> thrown because some other exception was thrown, there's really no more 
> detail for the EIIE itself. Promoting the cause's detail message to be 
> the detail message of the EIIE just seems wrong to me.

I think even VM removes the assert, I don't see how EIIE includes
the detail message is wrong?  It's consistent with the
Throwable(Throwable cause) constructor.

> Did this come about through the new code that saves the original cause 
> of the EIIE so that it can be reported when the subsequent 
> NoClassDefFoundError is thrown due to the class being in the erroneous 
> state? (I don't recall if that actually got pushed.)

I am not sure but I don't think so.  I ran into this when I develop
the bootstrap methods.  I think this is a good EIIE clean up.

Mandy

From mandy.chung at oracle.com  Thu Aug 16 17:57:01 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 16 Aug 2018 10:57:01 -0700
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <OFE236AB4F.C720ABBD-ON002582EB.0030A93D-802582EB.0032F109@notes.na.collabserv.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
 <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
 <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>
 <e9e19390-a0ca-9bf8-24b7-3b033a676680@oracle.com>
 <OFE236AB4F.C720ABBD-ON002582EB.0030A93D-802582EB.0032F109@notes.na.collabserv.com>
Message-ID: <e6867747-c062-8f81-df35-7d9c62970016@oracle.com>



On 8/16/18 2:16 AM, Adam Farley8 wrote:
> Hi Mandy,
> 
> I request that you review this for 8u.
> 
> ------------------------------------------------------
> @@ -1398,10 +1398,18 @@
>  ? ? ? ? ?bundle = baseBundle;
>  ? ? ?}
> 
> + ? ?keepAlive(loader);
>  ? ? ?return bundle;
>  ?}
> 
>  ?/**
> + * Keeps the argument ClassLoader alive.
> + */
> + ? ?private static void keepAlive(ClassLoader loaderone){
> + ? ?//Do nothing.
> + ? ?}
> +
> + ? ?/**
>  ? * Checks if the given <code>List</code> is not null, not empty,
>  ? * not having null in its elements.
>  ? */
> ------------------------------------------------------

Looks fine. Nit: a space before "Do nothing" comment would be good.
No need for a new diff.

Mandy

From david.holmes at oracle.com  Thu Aug 16 22:22:06 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Aug 2018 08:22:06 +1000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
 <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>
Message-ID: <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>

On 17/08/2018 1:18 AM, mandy chung wrote:
> 
> 
> On 8/15/18 11:00 PM, David Holmes wrote:
>> Hi Mandy,
>>
>> Not a review - sorry :)
>>
>> On 16/08/2018 7:46 AM, mandy chung wrote:
>>> ExceptionInInitializerError(Throwable cause) sets the detail message 
>>> to null.? It'd be helpful to include a detail message rather than null
>>> as in Throwable(Throwable cause) that constructs a new throwable
>>> with a default message cause==null ? null : cause.toString().
>>>
>>> This would help troubleshooting of writing new bootstrap methods
>>> where VM currently asserts non-null linkage error message [1] where
>>> there are other solutions such as constructing the message in
>>> the VM or removing the assert.
>>
>> I think that's just a bug in the VM code making inappropriate 
>> assumptions! There shouldn't have to be a detail message, especially 
>> in a wrapping exception like ExceptionInInitializerError! It only gets 
>> thrown because some other exception was thrown, there's really no more 
>> detail for the EIIE itself. Promoting the cause's detail message to be 
>> the detail message of the EIIE just seems wrong to me.
> 
> I think even VM removes the assert, I don't see how EIIE includes
> the detail message is wrong?? It's consistent with the
> Throwable(Throwable cause) constructor.

I think it is wrong because the message is not that of the EIIE but that 
of the original exception.

If EIIE must have a detail message then that should just be something 
explicit like:

Caused by <cause exception type> : <cause detail message>

Unlike general Throwables that may or may not have a cause, a true EIIE 
must always have a cause when thrown by the JVM.

David
-----

>> Did this come about through the new code that saves the original cause 
>> of the EIIE so that it can be reported when the subsequent 
>> NoClassDefFoundError is thrown due to the class being in the erroneous 
>> state? (I don't recall if that actually got pushed.)
> 
> I am not sure but I don't think so.? I ran into this when I develop
> the bootstrap methods.? I think this is a good EIIE clean up.
> 
> Mandy

From joe.darcy at oracle.com  Thu Aug 16 23:48:19 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 16 Aug 2018 16:48:19 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
Message-ID: <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>

Hello,


On 8/15/2018 5:10 PM, mandy chung wrote:
>
>
> On 8/15/18 3:20 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> Just a question. Why does "private Throwable exception" field in 
>> ExceptionInInitializerError exist? Was it there before there was a 
>> "cause" in Throwable and later still remained there because of 
>> serialization format? Would it be possible to "simulate" its effect 
>> for serialization using "serialPersistentFields" and 
>> ObjectOutputStream.PutField?
>
> Thanks for asking.? I meant to mention this and it'd be nice to
> follow up this in a separate issue.
>
> The private exception field exists since 1.1 and kept there for
> serialization.? getException in existing releases returns the
> exception field.? I can't think of any way to remove the exception
> field in JDK n to deserialize it with older JDK x unless JDK x was
> changed to write the exception field with the cause or getException
> to return cause.

Just a quick comment, it is possible, although a bit tedious, to remove 
a field and retain serial compatibility if readObject/writeObject 
methods are added to the new version of the class. There are a few 
examples of doing this kind of conversion in the JDK, such as for 
BigInteger.

HTH,

-Joe

From mandy.chung at oracle.com  Thu Aug 16 23:54:37 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 16 Aug 2018 16:54:37 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
 <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>
Message-ID: <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>



On 8/16/18 4:48 PM, joe darcy wrote:
>>> Just a question. Why does "private Throwable exception" field in 
>>> ExceptionInInitializerError exist? Was it there before there was a 
>>> "cause" in Throwable and later still remained there because of 
>>> serialization format? Would it be possible to "simulate" its effect 
>>> for serialization using "serialPersistentFields" and 
>>> ObjectOutputStream.PutField?
>>
>> Thanks for asking.? I meant to mention this and it'd be nice to
>> follow up this in a separate issue.
>>
>> The private exception field exists since 1.1 and kept there for
>> serialization.? getException in existing releases returns the
>> exception field.? I can't think of any way to remove the exception
>> field in JDK n to deserialize it with older JDK x unless JDK x was
>> changed to write the exception field with the cause or getException
>> to return cause.
> 
> Just a quick comment, it is possible, although a bit tedious, to remove 
> a field and retain serial compatibility if readObject/writeObject 
> methods are added to the new version of the class. There are a few 
> examples of doing this kind of conversion in the JDK, such as for 
> BigInteger.


Thanks Joe.  In EIIE case, ideally we should remove the private
exception field and then write that to the serialize stream.
However, PutField::put requires the field to be present in
the current class; otherwise it throws IAE.

    ObjectOutputStream.PutField fields = s.putFields();
    fields.put("exception", getCause());

I haven't digged the history but I assume a field in BigInteger
was not renamed/removed.

Any other suggestion would be appreciated.

Mandy

From mearvk at outlook.com  Fri Aug 17 01:34:21 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 17 Aug 2018 01:34:21 +0000
Subject: Compile Error
Message-ID: <SN6PR07MB5022C9C34B145FC29088AA9DDA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>

Spot what's the issue here:

Compiling 4 files for BUILD_JIGSAW_TOOLS
Error occurred during initialization of VM
java.lang.NullPointerException
        at jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:176)
        at java.lang.System.initPhase1(java.base/System.java:802)

>>

make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed

From stuart.marks at oracle.com  Fri Aug 17 01:57:48 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 Aug 2018 18:57:48 -0700
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
 <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
 <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>
 <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>
Message-ID: <cac53456-ebae-d0d1-0380-7f938a19e076@oracle.com>



On 8/16/18 1:38 AM, Jaikiran Pai wrote:
>>> [1] https://bugs.openjdk.java.net/browse/JDK-7033681
> 
> Is this JIRA/change, something that I can contribute? If so, what would
> be the typical process for that? I have signed and approved OCA, but I
> don't know what's involved in submitting changes which involve javadoc
> changes - does this need CSR and will that CSR have to be filed after I
> submit the initial draft of the changed javadoc?

Hi Jaikiran,

I've unhidden some old comments, and I've added some new comments to 
JDK-7033681; please take a look. I was half-intending to fix this myself, but 
since you're volunteering, you're welcome to take a crack at it.

Note that while this is changing javadoc and doc comments the task is quite a 
bit more rigorous than merely updating documentation. The javadoc for public 
Java SE APIs is a *specification* and requires very precise language. It's not 
unusual for what are apparently small changes to go through several rounds of 
review. (Sorry if you already know this, but I wanted to make sure.)

Whether this requires a CSR depends on whether any normative text of the 
specification is changed. A simple clarification ("API note") can be added 
without a CSR. As the wording stands now, however, it seems like there is a 
mixture of normative and informative statements in the text; these should be 
teased apart and the informative statements placed into an API note. In 
addition, the normative text could probably be reworded to be more clear. (See 
my comments in the bug.) Such changes would probably need a CSR, even though 
they wouldn't actually change the intent of the specification.

If you're still with me, then dive right in! It'll probably be easiest to 
exchange drafts on the email list. I don't think a webrev is necessary, at least 
not yet. Once we've converged on final wording, I can help you file a CSR and 
push the change.

**

Regarding how mutator methods sometimes throw UOE and sometimes do not, this is 
an unfortunate inconsistency in the collections implementations. For example, 
consider the jshell transcript I've appended below. Some implementations throw 
UOE only if an actual mutation were to occur, whereas other implementations 
unconditionally throw UOE whenever a mutator method is called, even if it 
wouldn't result in any actual mutation. Personally, I prefer the stricter 
approach; the unmodifiable collections I added recently all behave strictly. 
However, other implementations do not, and we've been reluctant to change their 
behavior because of the possibility of introducing exceptions into previously 
working (but likely buggy, or at least sloppy) code.

Note that the behavior of the collections is *not* specified to this level of 
detail. It's unfortunately left rather vague, but I think it has to be this way, 
since different collections implementations have diverse behaviors.

Thanks,

s'marks




jshell> Arrays.asList("a")
$26 ==> [a]

jshell> $26.remove("b")
$27 ==> false

jshell> Collections.singletonList("a")
$28 ==> [a]

jshell> $28.remove("b")
$29 ==> false

jshell> Collections.unmodifiableList(Arrays.asList("a"))
$30 ==> [a]

jshell> $30.remove("b")
|  Exception java.lang.UnsupportedOperationException
|        at Collections$UnmodifiableCollection.remove (Collections.java:1061)
|        at (#31:1)

jshell> List.of("a")
$32 ==> [a]

jshell> $32.remove("b")
|  Exception java.lang.UnsupportedOperationException
|        at ImmutableCollections.uoe (ImmutableCollections.java:71)
|        at ImmutableCollections$AbstractImmutableCollection.remove 
(ImmutableCollections.java:78)
|        at (#33:1)



From david.holmes at oracle.com  Fri Aug 17 02:42:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Aug 2018 12:42:32 +1000
Subject: Compile Error
In-Reply-To: <SN6PR07MB5022C9C34B145FC29088AA9DDA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C9C34B145FC29088AA9DDA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <c8b663ea-3bc3-f5a5-7bb9-6de98d1e79ac@oracle.com>

Max,

On 17/08/2018 11:34 AM, mr rupplin wrote:
> Spot what's the issue here:
> 
> Compiling 4 files for BUILD_JIGSAW_TOOLS
> Error occurred during initialization of VM
> java.lang.NullPointerException
>          at jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:176)
>          at java.lang.System.initPhase1(java.base/System.java:802)

You are making changes to the core OpenJDK code and we can't see what 
you have done (not that anyone is here to do your debugging for you). 
Your changes have resulted in a NullPointerException whilst setting (or 
removing) some of the initial system properties during early 
initialization of the class libraries.

You need to look at your changes and debug things. I will say that the 
initialization sequence for the system is very fragile and easily 
broken. If you have added new static initialization actions to core 
classes then you may well have violated numerous 
assumptions/expectations of the initialization sequence. You can't use 
arbitrary Java code within the initialization code of core library 
classes because you can get unresolvable circular dependencies.

As others have stated, making changes to core OpenJDK classes is not a 
trivial matter, and you need a certain level of OpenJDK experience and 
expertise to be able to manage it.

David

>>>
> 
> make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed
> 

From Yang.Zhang at arm.com  Fri Aug 17 04:13:33 2018
From: Yang.Zhang at arm.com (Yang Zhang)
Date: Fri, 17 Aug 2018 04:13:33 +0000
Subject: RFR: 8209465: [TESTBUG] Fix jtreg test cases of jdk about file name
 too long in AUFS file system
Message-ID: <AM0PR08MB355494B5962A34FC107E816D8E3D0@AM0PR08MB3554.eurprd08.prod.outlook.com>

Hi,



Could you please help review the fix to jtreg test cases in jdk?

java/io/File/DeleteOnExitLong.java
java/io/File/MaxPathLength.java



The failure happens in Linux AUFS file system. The maximum file name length in AUFS is 242.



JBS: https://bugs.openjdk.java.net/browse/JDK-8209465

Webrev: http://cr.openjdk.java.net/~yzhang/8209465/webrev.00/



Regards,

Yang


From peter.levart at gmail.com  Fri Aug 17 07:24:58 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 17 Aug 2018 09:24:58 +0200
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
 <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>
 <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
Message-ID: <61371c5a-1b2b-29e1-7fe4-2a5af5c2aac4@gmail.com>



On 08/17/2018 01:54 AM, mandy chung wrote:
>
>
> On 8/16/18 4:48 PM, joe darcy wrote:
>>>> Just a question. Why does "private Throwable exception" field in 
>>>> ExceptionInInitializerError exist? Was it there before there was a 
>>>> "cause" in Throwable and later still remained there because of 
>>>> serialization format? Would it be possible to "simulate" its effect 
>>>> for serialization using "serialPersistentFields" and 
>>>> ObjectOutputStream.PutField?
>>>
>>> Thanks for asking.? I meant to mention this and it'd be nice to
>>> follow up this in a separate issue.
>>>
>>> The private exception field exists since 1.1 and kept there for
>>> serialization.? getException in existing releases returns the
>>> exception field.? I can't think of any way to remove the exception
>>> field in JDK n to deserialize it with older JDK x unless JDK x was
>>> changed to write the exception field with the cause or getException
>>> to return cause.
>>
>> Just a quick comment, it is possible, although a bit tedious, to 
>> remove a field and retain serial compatibility if 
>> readObject/writeObject methods are added to the new version of the 
>> class. There are a few examples of doing this kind of conversion in 
>> the JDK, such as for BigInteger.
>
>
> Thanks Joe.? In EIIE case, ideally we should remove the private
> exception field and then write that to the serialize stream.
> However, PutField::put requires the field to be present in
> the current class; otherwise it throws IAE.
>
> ?? ObjectOutputStream.PutField fields = s.putFields();
> ?? fields.put("exception", getCause());

Not necessarily. Check ConcurrentHashMap for example. It contains 
several "pseudo" fields, declared with the "serialPersistentFields" 
static final field.

The only problem with this approach is that while deserializing the 
Throwable part of the ExceptionInInitializerError from the serial stream 
produced by an old version of EIIE, the cause field will already be 
deserialized as null and later in ExceptionInInitializerError.readObject 
when "exception" pseudo field is read-in, its value would have to be 
written over Throwable.cause field, but public API will not allow that 
(re-initialization of cause is not permitted), so some package-private 
API would have to be used to overwrite "cause".

But this same problem is present even if you keep the physical 
"exception" field in the ExceptionInInitializerError. You have to be 
prepared to deserialize an old version of EIIE where the "cause" is null 
and the "exception" is non-null.

Regards, Peter

>
> I haven't digged the history but I assume a field in BigInteger
> was not renamed/removed.
>
> Any other suggestion would be appreciated.
>
> Mandy


From adam.farley at uk.ibm.com  Fri Aug 17 09:58:34 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 17 Aug 2018 10:58:34 +0100
Subject: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix included)
In-Reply-To: <e6867747-c062-8f81-df35-7d9c62970016@oracle.com>
References: <OF73090A20.AEC24ED7-ON002582E5.00555A7E-802582E5.00563E62@notes.na.collabserv.com>
 <cccb972f-ba27-686f-2c38-aab5644d779e@oracle.com>
 <CAMOCf+jNLxR=0on74C476-5fi9Cgn--WvZPZTtqobRWK5LaMow@mail.gmail.com>
 <5d38fbd7-816d-9dfb-10a0-e018a1ba7f8f@oracle.com>
 <CAMOCf+hOQFF+Ym=4KgkMCt=ViLMP7Oj3bfvZLULkYQ2v4Q3UvQ@mail.gmail.com>
 <OF892E1194.0FD5391B-ON002582EA.0053B9BA-802582EA.005521F5@LocalDomain>
 <OFD5CD6047.36213180-ON002582EA.00567837-802582EA.0056863C@notes.na.collabserv.com>
 <e9e19390-a0ca-9bf8-24b7-3b033a676680@oracle.com>
 <OFE236AB4F.C720ABBD-ON002582EB.0030A93D-802582EB.0032F109@notes.na.collabserv.com>
 <e6867747-c062-8f81-df35-7d9c62970016@oracle.com>
Message-ID: <OF96C75547.8EBEB0E5-ON002582EC.0036A41C-802582EC.0036CD21@notes.na.collabserv.com>

Hi Mandy,

The extra space is fine.

In hindsight, you could probably rename "loaderone" to just "loader" too.

Thanks for helping with this. :)

Best Regards

Adam Farley 
OpenJDK Team 
Runtimes 
IBM 


mandy chung <mandy.chung at oracle.com> wrote on 16/08/2018 18:57:01:

> From: mandy chung <mandy.chung at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>, Hans Boehm 
> <hboehm at google.com>, i18n-dev at openjdk.java.net
> Date: 16/08/2018 18:57
> Subject: Re: RFR 8209184: JDK8 ResourceBundle vulnerable to GC (fix 
included)
> 
> 
> 
> On 8/16/18 2:16 AM, Adam Farley8 wrote:
> > Hi Mandy,
> > 
> > I request that you review this for 8u.
> > 
> > ------------------------------------------------------
> > @@ -1398,10 +1398,18 @@
> >           bundle = baseBundle;
> >       }
> > 
> > +    keepAlive(loader);
> >       return bundle;
> >   }
> > 
> >   /**
> > + * Keeps the argument ClassLoader alive.
> > + */
> > +    private static void keepAlive(ClassLoader loaderone){
> > +    //Do nothing.
> > +    }
> > +
> > +    /**
> >    * Checks if the given <code>List</code> is not null, not empty,
> >    * not having null in its elements.
> >    */
> > ------------------------------------------------------
> 
> Looks fine. Nit: a space before "Do nothing" comment would be good.
> No need for a new diff.
> 
> Mandy
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From claes.redestad at oracle.com  Fri Aug 17 10:56:31 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 17 Aug 2018 12:56:31 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
Message-ID: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>

Hi,

a small improvement can be seen on startup tests that exercise lambdas 
and ISC if we change the interning mechanism of MethodTypes slightly so 
that lookup can be done without wrapping the lookup key in a WeakEntry.

Bug: https://bugs.openjdk.java.net/browse/JDK-8209633
Webrev: http://cr.openjdk.java.net/~redestad/8209633/open.00/

Testing: jdk-tier1+jdk-tier2

Thanks!

/Claes

From roger.riggs at oracle.com  Fri Aug 17 13:16:07 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Aug 2018 09:16:07 -0400
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
 <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>
 <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>
Message-ID: <6263a816-c22a-bcca-736e-aa8cd9272efc@oracle.com>

Hi David,

Exceptions should have a detail message that is useful.
For EIIE, all of the salient information is in the message of the cause and
is much more useful that something generic that just echos the EIIE's type.
Without a stacktrace EIIE, with a generic message is nearly useless.

Generally, where an exception is caught just to be wrapped and 
propagated with a
different type, the message from the underlying cause is more useful to 
report.

$.02, Roger

On 8/16/18 6:22 PM, David Holmes wrote:
> On 17/08/2018 1:18 AM, mandy chung wrote:
>>
>>
>> On 8/15/18 11:00 PM, David Holmes wrote:
>>> Hi Mandy,
>>>
>>> Not a review - sorry :)
>>>
>>> On 16/08/2018 7:46 AM, mandy chung wrote:
>>>> ExceptionInInitializerError(Throwable cause) sets the detail 
>>>> message to null.? It'd be helpful to include a detail message 
>>>> rather than null
>>>> as in Throwable(Throwable cause) that constructs a new throwable
>>>> with a default message cause==null ? null : cause.toString().
>>>>
>>>> This would help troubleshooting of writing new bootstrap methods
>>>> where VM currently asserts non-null linkage error message [1] where
>>>> there are other solutions such as constructing the message in
>>>> the VM or removing the assert.
>>>
>>> I think that's just a bug in the VM code making inappropriate 
>>> assumptions! There shouldn't have to be a detail message, especially 
>>> in a wrapping exception like ExceptionInInitializerError! It only 
>>> gets thrown because some other exception was thrown, there's really 
>>> no more detail for the EIIE itself. Promoting the cause's detail 
>>> message to be the detail message of the EIIE just seems wrong to me.
>>
>> I think even VM removes the assert, I don't see how EIIE includes
>> the detail message is wrong?? It's consistent with the
>> Throwable(Throwable cause) constructor.
>
> I think it is wrong because the message is not that of the EIIE but 
> that of the original exception.
>
> If EIIE must have a detail message then that should just be something 
> explicit like:
>
> Caused by <cause exception type> : <cause detail message>
>
> Unlike general Throwables that may or may not have a cause, a true 
> EIIE must always have a cause when thrown by the JVM.
>
> David
> -----
>
>>> Did this come about through the new code that saves the original 
>>> cause of the EIIE so that it can be reported when the subsequent 
>>> NoClassDefFoundError is thrown due to the class being in the 
>>> erroneous state? (I don't recall if that actually got pushed.)
>>
>> I am not sure but I don't think so.? I ran into this when I develop
>> the bootstrap methods.? I think this is a good EIIE clean up.
>>
>> Mandy


From peter.levart at gmail.com  Fri Aug 17 14:04:23 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 17 Aug 2018 16:04:23 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
Message-ID: <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>

Hi Claes,

Nice trick. You made MethodType(s) and WeakEntry(s) holding them equal, 
respecting the equals()/hashCode() contract. When WeakEntry looses the 
referent it is left equal to itself only, which is enough for expunging 
it from map.

Regards, Peter

On 08/17/2018 12:56 PM, Claes Redestad wrote:
> Hi,
>
> a small improvement can be seen on startup tests that exercise lambdas 
> and ISC if we change the interning mechanism of MethodTypes slightly 
> so that lookup can be done without wrapping the lookup key in a 
> WeakEntry.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209633
> Webrev: http://cr.openjdk.java.net/~redestad/8209633/open.00/
>
> Testing: jdk-tier1+jdk-tier2
>
> Thanks!
>
> /Claes


From claes.redestad at oracle.com  Fri Aug 17 14:32:41 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 17 Aug 2018 16:32:41 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
Message-ID: <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>

Hi Peter,

On 2018-08-17 16:04, Peter Levart wrote:
> Hi Claes,
>
> Nice trick.

thanks!

> You made MethodType(s) and WeakEntry(s) holding them equal, respecting 
> the equals()/hashCode() contract. When WeakEntry looses the referent 
> it is left equal to itself only, which is enough for expunging it from 
> map.

Good summary. Do you think we need a few comments to spell out these 
intricacies?

/Claes

From peter.levart at gmail.com  Fri Aug 17 14:38:51 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 17 Aug 2018 16:38:51 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
 <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
Message-ID: <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>



On 08/17/2018 04:32 PM, Claes Redestad wrote:
> Hi Peter,
>
> On 2018-08-17 16:04, Peter Levart wrote:
>> Hi Claes,
>>
>> Nice trick.
>
> thanks!
>
>> You made MethodType(s) and WeakEntry(s) holding them equal, 
>> respecting the equals()/hashCode() contract. When WeakEntry looses 
>> the referent it is left equal to itself only, which is enough for 
>> expunging it from map.
>
> Good summary. Do you think we need a few comments to spell out these 
> intricacies?

Yes, perhaps just pointers from the two equals() methods to each other, 
explaining that they are actually one method which is split into two 
unrelated classes.

Peter


From jason_mehrens at hotmail.com  Fri Aug 17 15:05:32 2018
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 17 Aug 2018 15:05:32 +0000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
 <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>,
 <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
Message-ID: <CY4PR18MB132052257787D6F11E5D4164833D0@CY4PR18MB1320.namprd18.prod.outlook.com>

Hi Mandy,

This what we were doing in the past and has examples of removing fields with expected tests:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html

However, this case is a little different because it actually disallows subsequent initCause.  I would assume that will get tricky if you deserialize the old binary form in a newer JDK because we would have to jump through some hoops to update null to the cause exception.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of mandy chung <mandy.chung at oracle.com>
Sent: Thursday, August 16, 2018 6:54 PM
To: joe darcy; Peter Levart
Cc: core-libs-dev
Subject: Re: RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given



On 8/16/18 4:48 PM, joe darcy wrote:
>>> Just a question. Why does "private Throwable exception" field in
>>> ExceptionInInitializerError exist? Was it there before there was a
>>> "cause" in Throwable and later still remained there because of
>>> serialization format? Would it be possible to "simulate" its effect
>>> for serialization using "serialPersistentFields" and
>>> ObjectOutputStream.PutField?
>>
>> Thanks for asking.  I meant to mention this and it'd be nice to
>> follow up this in a separate issue.
>>
>> The private exception field exists since 1.1 and kept there for
>> serialization.  getException in existing releases returns the
>> exception field.  I can't think of any way to remove the exception
>> field in JDK n to deserialize it with older JDK x unless JDK x was
>> changed to write the exception field with the cause or getException
>> to return cause.
>
> Just a quick comment, it is possible, although a bit tedious, to remove
> a field and retain serial compatibility if readObject/writeObject
> methods are added to the new version of the class. There are a few
> examples of doing this kind of conversion in the JDK, such as for
> BigInteger.


Thanks Joe.  In EIIE case, ideally we should remove the private
exception field and then write that to the serialize stream.
However, PutField::put requires the field to be present in
the current class; otherwise it throws IAE.

    ObjectOutputStream.PutField fields = s.putFields();
    fields.put("exception", getCause());

I haven't digged the history but I assume a field in BigInteger
was not renamed/removed.

Any other suggestion would be appreciated.

Mandy

From jai.forums2013 at gmail.com  Fri Aug 17 15:07:41 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 17 Aug 2018 20:37:41 +0530
Subject: Arrays.asList returned List - Its modifying/write-through
 semantics
In-Reply-To: <cac53456-ebae-d0d1-0380-7f938a19e076@oracle.com>
References: <f43525a8-3fd1-4b96-2d75-9c0632dc45fe@gmail.com>
 <c785379c-5322-1415-98c8-c1b98858bdb9@oracle.com>
 <be058c41-ab0f-77f8-8c15-9a3ecb6a522e@gmail.com>
 <60a456f1-b906-fe74-0def-9d3b22404db2@gmail.com>
 <cac53456-ebae-d0d1-0380-7f938a19e076@oracle.com>
Message-ID: <6a665303-1b7e-d12a-a662-83baf37c8362@gmail.com>

Thank you Roger and Stuart for the detailed reply. Comments inline.


On 17/08/18 7:27 AM, Stuart Marks wrote:
> ?
>
> Note that while this is changing javadoc and doc comments the task is
> quite a bit more rigorous than merely updating documentation. The
> javadoc for public Java SE APIs is a *specification* and requires very
> precise language. It's not unusual for what are apparently small
> changes to go through several rounds of review. (Sorry if you already
> know this, but I wanted to make sure.)
I understand :) I decided to pick this up since it's been around for a
few years now and I don't think anyone is in a hurry to have this done.
So this will give me enough time to understand the contribution process
as well as go through as many review rounds as necessary to get it right.

>
> Whether this requires a CSR depends on whether any normative text of
> the specification is changed. A simple clarification ("API note") can
> be added without a CSR. As the wording stands now, however, it seems
> like there is a mixture of normative and informative statements in the
> text; these should be teased apart and the informative statements
> placed into an API note. In addition, the normative text could
> probably be reworded to be more clear. (See my comments in the bug.)
> Such changes would probably need a CSR, even though they wouldn't
> actually change the intent of the specification.
>
> If you're still with me, then dive right in! It'll probably be easiest
> to exchange drafts on the email list. 
I'll come up with an initial version of the change (based on your inputs
that I see in the JIRA) and send it out to this mailing list for review,
in the coming days.

Thanks again for the detailed reply.

-Jaikiran


From volker.simonis at gmail.com  Fri Aug 17 15:12:32 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 17 Aug 2018 17:12:32 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI function
 legal?
Message-ID: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>

Hi,

we've recently discovered a problem with Console.readPassword() which
failed to restore the correct echo mode on Linux/s390x [1]. We could
finally track this down to a "bug" [2] in the s390x template
interpreter which failed to call the "result handler" after a native
call. For jboolean return types, the "result handler" merges all
values > 0 into 1 (i.e. JNI_TRUE). Not calling the result handler
after returning from native calls resulted in cases where non-zero
jboolean values returned from native functions where interpreted as
zero (i.e. JNI_FALSE).

The offending code in Console_md.c looks as follows:

#define ECHO    8

JNIEXPORT jboolean JNICALL
Java_java_io_Console_echo(...) {

    jboolean old;
    ...
    old = (tio.c_lflag & ECHO);
    ...
    return old;
}

The intention of this code is to return "true" if the ECHO flag was
set but it really returns the value of ECHO (which is defined as '8'
in a system header).

The question now is, if a Java SE compatible VM guarantees that any
arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
and only a zero valued jboolean will be interpreted as "JNI_FALSE"?

Or, the other way round, is the normalization performed by the HotSpot
result handlers necessary (i.e. enforced by the specification) or just
a convenience to fix broken code like the above from Console.echo()?

All I could find from the Specification so far is the following, which
seems to suggest that only JNI_TRUE/JNI_FASLE are valid values for a
jboolean, but I'm not completely sure...

From: JNI Types and Data Structures [3]

Java "boolean" == JNI "jboolean" == unsigned 8 bits

The following definition is provided for convenience.

#define JNI_FALSE  0
#define JNI_TRUE   1

From: JVMLS, ? 2.3.4. The boolean Type [4]

Although the Java Virtual Machine defines a boolean type, it only
provides very limited support for it. There are no Java Virtual
Machine instructions solely dedicated to operations on boolean values.
Instead, expressions in the Java programming language that operate on
boolean values are compiled to use values of the Java Virtual Machine
int data type.

The Java Virtual Machine encodes boolean array components using 1 to
represent true and 0 to represent false. Where Java programming
language boolean values are mapped by compilers to values of Java
Virtual Machine type int, the compilers must use the same encoding.

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/thread.html#54479
[2] https://bugs.openjdk.java.net/browse/JDK-8209637
[3] https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html
[4] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.3.4

From mandy.chung at oracle.com  Fri Aug 17 15:20:03 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 17 Aug 2018 08:20:03 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <CY4PR18MB132052257787D6F11E5D4164833D0@CY4PR18MB1320.namprd18.prod.outlook.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
 <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>
 <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
 <CY4PR18MB132052257787D6F11E5D4164833D0@CY4PR18MB1320.namprd18.prod.outlook.com>
Message-ID: <ff31a1b0-ed3b-6775-0ee3-2af310f52cba@oracle.com>

Hi Peter, Jason, Joe,

Thanks for the pointers.  I have missed the use of
serialPersistentFields (thanks to Peter for calling this out).  I read
the javadoc and serialization spec but that didn't come clearly to me.
It'd be good to include an example in the javadoc (will file a JBS issue).

W.r.t. the package-private API to set the cause in EIIE [1], yes it's
needed and it's done in webrev.01.  Let me redo the
readObject/writeObject part and send a new webrev.

Mandy
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.01/src/java.base/share/classes/java/lang/Throwable.java.sdiff.html

On 8/17/18 8:05 AM, Jason Mehrens wrote:
> Hi Mandy,
> 
> This what we were doing in the past and has examples of removing
> fields with expected tests: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html >
> However, this case is a little different because it actually
> disallows subsequent initCause.  I would assume that will get tricky
> if you deserialize the old binary form in a newer JDK because we
> would have to jump through some hoops to update null to the cause
> exception.
> 
> Jason
> 

From mandy.chung at oracle.com  Fri Aug 17 17:07:55 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 17 Aug 2018 10:07:55 -0700
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
 <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
 <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>
Message-ID: <aee7d6dc-4805-d033-9db5-97d70ee642ab@oracle.com>



On 8/17/18 7:38 AM, Peter Levart wrote:
> 
> 
> On 08/17/2018 04:32 PM, Claes Redestad wrote:
>> Hi Peter,
>>
>> On 2018-08-17 16:04, Peter Levart wrote:
>>> Hi Claes,
>>>
>>> Nice trick.

+1

>>> You made MethodType(s) and WeakEntry(s) holding them equal, 
>>> respecting the equals()/hashCode() contract. When WeakEntry looses 
>>> the referent it is left equal to itself only, which is enough for 
>>> expunging it from map.
>>
>> Good summary. Do you think we need a few comments to spell out these 
>> intricacies?
> 
> Yes, perhaps just pointers from the two equals() methods to each other, 
> explaining that they are actually one method which is split into two 
> unrelated classes.

It'd be worth to document this as javadoc of these two equals methods
(that's probably what you are thinking).

Mandy

From roger.riggs at oracle.com  Fri Aug 17 17:15:38 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Aug 2018 13:15:38 -0400
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
Message-ID: <b0ea35fb-5b6e-6367-605a-645979e6e1c7@oracle.com>

Hi Volker,

This may be more of a hotspot question than core-libs.

This seems like a practical feature of the implementation and a convenience
to match the conventions of C/C++ with JNI.

It might be worth adding a test to verify the assumptions between Java 
and Native.

$.02, Roger


On 8/17/18 11:12 AM, Volker Simonis wrote:
> Hi,
>
> we've recently discovered a problem with Console.readPassword() which
> failed to restore the correct echo mode on Linux/s390x [1]. We could
> finally track this down to a "bug" [2] in the s390x template
> interpreter which failed to call the "result handler" after a native
> call. For jboolean return types, the "result handler" merges all
> values > 0 into 1 (i.e. JNI_TRUE). Not calling the result handler
> after returning from native calls resulted in cases where non-zero
> jboolean values returned from native functions where interpreted as
> zero (i.e. JNI_FALSE).
>
> The offending code in Console_md.c looks as follows:
>
> #define ECHO    8
>
> JNIEXPORT jboolean JNICALL
> Java_java_io_Console_echo(...) {
>
>      jboolean old;
>      ...
>      old = (tio.c_lflag & ECHO);
>      ...
>      return old;
> }
>
> The intention of this code is to return "true" if the ECHO flag was
> set but it really returns the value of ECHO (which is defined as '8'
> in a system header).
>
> The question now is, if a Java SE compatible VM guarantees that any
> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
> and only a zero valued jboolean will be interpreted as "JNI_FALSE"?
>
> Or, the other way round, is the normalization performed by the HotSpot
> result handlers necessary (i.e. enforced by the specification) or just
> a convenience to fix broken code like the above from Console.echo()?
>
> All I could find from the Specification so far is the following, which
> seems to suggest that only JNI_TRUE/JNI_FASLE are valid values for a
> jboolean, but I'm not completely sure...
>
> From: JNI Types and Data Structures [3]
>
> Java "boolean" == JNI "jboolean" == unsigned 8 bits
>
> The following definition is provided for convenience.
>
> #define JNI_FALSE  0
> #define JNI_TRUE   1
>
> From: JVMLS, ? 2.3.4. The boolean Type [4]
>
> Although the Java Virtual Machine defines a boolean type, it only
> provides very limited support for it. There are no Java Virtual
> Machine instructions solely dedicated to operations on boolean values.
> Instead, expressions in the Java programming language that operate on
> boolean values are compiled to use values of the Java Virtual Machine
> int data type.
>
> The Java Virtual Machine encodes boolean array components using 1 to
> represent true and 0 to represent false. Where Java programming
> language boolean values are mapped by compilers to values of Java
> Virtual Machine type int, the compilers must use the same encoding.
>
> Thank you and best regards,
> Volker
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/thread.html#54479
> [2] https://bugs.openjdk.java.net/browse/JDK-8209637
> [3] https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html
> [4] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.3.4


From shade at redhat.com  Fri Aug 17 17:25:49 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 17 Aug 2018 19:25:49 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
Message-ID: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>

On 08/17/2018 05:12 PM, Volker Simonis wrote:
> The offending code in Console_md.c looks as follows:
> 
> #define ECHO    8
> 
> JNIEXPORT jboolean JNICALL
> Java_java_io_Console_echo(...) {
> 
>     jboolean old;
>     ...
>     old = (tio.c_lflag & ECHO);
>     ...
>     return old;
> }
> 
> The intention of this code is to return "true" if the ECHO flag was
> set but it really returns the value of ECHO (which is defined as '8'
> in a system header).
> 
> The question now is, if a Java SE compatible VM guarantees that any
> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
> and only a zero valued jboolean will be interpreted as "JNI_FALSE"?
> 
> Or, the other way round, is the normalization performed by the HotSpot
> result handlers necessary (i.e. enforced by the specification) or just
> a convenience to fix broken code like the above from Console.echo()?

I think this is intentional aftermath of boolean value normalization:
  https://bugs.openjdk.java.net/browse/JDK-8161720

So, Java_java_io_Console_echo looks broken and needs to be fixed, by e.g.:

-   old = (tio.c_lflag & ECHO);
+   old = (tio.c_lflag & ECHO) != 0;

Thanks,
-Aleksey


From xueming.shen at oracle.com  Fri Aug 17 17:38:48 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Aug 2018 10:38:48 -0700
Subject: Is returning a value != '0' or '1' as jboolean from a JNI function
 legal?
In-Reply-To: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
Message-ID: <5B770828.1060805@oracle.com>

On 08/17/2018 10:25 AM, Aleksey Shipilev wrote:
> On 08/17/2018 05:12 PM, Volker Simonis wrote:
>> The offending code in Console_md.c looks as follows:
>>
>> #define ECHO    8
>>
>> JNIEXPORT jboolean JNICALL
>> Java_java_io_Console_echo(...) {
>>
>>      jboolean old;
>>      ...
>>      old = (tio.c_lflag&  ECHO);
>>      ...
>>      return old;
>> }
>>
>> The intention of this code is to return "true" if the ECHO flag was
>> set but it really returns the value of ECHO (which is defined as '8'
>> in a system header).
>>
>> The question now is, if a Java SE compatible VM guarantees that any
>> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
>> and only a zero valued jboolean will be interpreted as "JNI_FALSE"?
>>
>> Or, the other way round, is the normalization performed by the HotSpot
>> result handlers necessary (i.e. enforced by the specification) or just
>> a convenience to fix broken code like the above from Console.echo()?
> I think this is intentional aftermath of boolean value normalization:
>    https://bugs.openjdk.java.net/browse/JDK-8161720
>
> So, Java_java_io_Console_echo looks broken and needs to be fixed, by e.g.:
>
> -   old = (tio.c_lflag&  ECHO);
> +   old = (tio.c_lflag&  ECHO) != 0;
>
> Thanks,
> -Aleksey
>

Yes, the code in Console_md.c need/will be updated to fix this issue. We planed and
tried in early circle of jdk11 when working on 8194750, at least for the newly added
code.  But change had been backed out for other reason. Will fix this specific one in
12. But the existing code is about decade old, I would assume you probably still need
to fix the s390x part as a "regression".

Thanks!
Sherman


From mearvk at outlook.com  Fri Aug 17 17:40:43 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 17 Aug 2018 17:40:43 +0000
Subject: Moderator Responsibilities
Message-ID: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>

Hello.


I have been contacted by someone who has stated that there are complaints that we ask the channel about debug questions.  I have 12+ years in Software and a Masters Degree in Computer Science.


There will be no more kid games. If you are asked, please answer fully and promptly.  Debugging a long compile stack can be complicated.


Also, if recurring questions become irksome make a JDK wiki on github.  This is the least we can expect.


That is all.


Thank you for your understanding.


Max R.


(Sr. Software Fellow)

From joe.darcy at oracle.com  Fri Aug 17 17:47:51 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 17 Aug 2018 10:47:51 -0700
Subject: Moderator Responsibilities
In-Reply-To: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <ce5fc417-5f73-0be1-6c17-627b8d36eb4d@oracle.com>

This list is for discussions related to the development of the JDK's 
core libraries.

It is not a no-cost support or engineering services offering and should 
be treated accordingly.

-Joe



From jbluettduncan at gmail.com  Fri Aug 17 19:11:22 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 17 Aug 2018 20:11:22 +0100
Subject: Moderator Responsibilities
In-Reply-To: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <CAPMys84P40+Rz2pTek6+6dXdJfnxiWrFa67-JFoZDVOM76L72w@mail.gmail.com>

Hi Mr Rupplin,

I can't speak for anyone else, but I'm personally puzzled by your email.
Could you clarify what you mean by "There will be no more kid games. If you
are asked, please answer fully and promptly.  Debugging a long compile
stack can be complicated."? I ask because it came across as antagonistic to
me, but I'm sure didn't mean to!

Do not the OpenJDK wiki <https://wiki.openjdk.java.net/> or the Adoption
group's "New Contributor" page
<https://wiki.openjdk.java.net/display/Adoption/New+Contributor> give you
the information you need to work with the OpenJDK sources? If not, is there
any additional info that you think someone with relevant permissions could
add to the wiki to make working with the sources easier?

Cheers,
Jonathan

On Fri, 17 Aug 2018 at 18:41, mr rupplin <mearvk at outlook.com> wrote:

> Hello.
>
>
> I have been contacted by someone who has stated that there are complaints
> that we ask the channel about debug questions.  I have 12+ years in
> Software and a Masters Degree in Computer Science.
>
>
> There will be no more kid games. If you are asked, please answer fully and
> promptly.  Debugging a long compile stack can be complicated.
>
>
> Also, if recurring questions become irksome make a JDK wiki on github.
> This is the least we can expect.
>
>
> That is all.
>
>
> Thank you for your understanding.
>
>
> Max R.
>
>
> (Sr. Software Fellow)
>

From jbluettduncan at gmail.com  Fri Aug 17 21:03:22 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 17 Aug 2018 22:03:22 +0100
Subject: Moderator Responsibilities
In-Reply-To: <SN6PR07MB5022D77D936DD053DE9689B4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50224ADE89F559C271A690E4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
 <CAPMys84P40+Rz2pTek6+6dXdJfnxiWrFa67-JFoZDVOM76L72w@mail.gmail.com>
 <SN6PR07MB5022D77D936DD053DE9689B4DA3D0@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <CAPMys85zSCapkJ8wqTMjmtNHYm9UM_wrMwAJQ9zX30e89LRAQg@mail.gmail.com>

Hi Max (I only just realised that you gave your first name in your original
email!),

I'm still unclear on what you meant earlier by "no more kid games", and
also what you mean by "I am not here to adjust maturity in channel.  Agree
to get along here like adults is what". Did any earlier communications you
had on one of the OpenJDK mailing lists leave you disappointed or
something? ??

Kind regards,
Jonathan

On Fri, 17 Aug 2018, 20:38 mr rupplin, <mearvk at outlook.com> wrote:

> Great.  I'll check out the wiki.  I am not here to adjust maturity in
> channel.  Agree to get along here like adults is what.
>
> Ok.
>
>
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Jonathan Bluett-Duncan <jbluettduncan at gmail.com>
> *Sent:* Friday, August 17, 2018 3:11:22 PM
> *To:* mearvk at outlook.com
> *Cc:* core-libs-dev
> *Subject:* Re: Moderator Responsibilities
>
> Hi Mr Rupplin,
>
> I can't speak for anyone else, but I'm personally puzzled by your email.
> Could you clarify what you mean by "There will be no more kid games. If you
> are asked, please answer fully and promptly.  Debugging a long compile
> stack can be complicated."? I ask because it came across as antagonistic to
> me, but I'm sure didn't mean to!
>
> Do not the OpenJDK wiki <https://wiki.openjdk.java.net/> or the Adoption
> group's "New Contributor" page
> <https://wiki.openjdk.java.net/display/Adoption/New+Contributor> give you
> the information you need to work with the OpenJDK sources? If not, is there
> any additional info that you think someone with relevant permissions could
> add to the wiki to make working with the sources easier?
>
> Cheers,
> Jonathan
>
> On Fri, 17 Aug 2018 at 18:41, mr rupplin <mearvk at outlook.com> wrote:
>
>> Hello.
>>
>>
>> I have been contacted by someone who has stated that there are complaints
>> that we ask the channel about debug questions.  I have 12+ years in
>> Software and a Masters Degree in Computer Science.
>>
>>
>> There will be no more kid games. If you are asked, please answer fully
>> and promptly.  Debugging a long compile stack can be complicated.
>>
>>
>> Also, if recurring questions become irksome make a JDK wiki on github.
>> This is the least we can expect.
>>
>>
>> That is all.
>>
>>
>> Thank you for your understanding.
>>
>>
>> Max R.
>>
>>
>> (Sr. Software Fellow)
>>
>

From huizhe.wang at oracle.com  Fri Aug 17 21:39:36 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 17 Aug 2018 14:39:36 -0700
Subject: RFR(JDK12/NIO) 8209576: java.nio.file.Files.writeString writes garbled
 UTF-16 instead of UTF-8
Message-ID: <5B774098.3090506@oracle.com>

Hi,

Please review a fix for a condition where a code conversion was skipped 
incorrectly resulting in a wrong byte array being written into the file.

JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209576/webrev/

Thanks,
Joe


From xueming.shen at oracle.com  Fri Aug 17 21:49:42 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Aug 2018 14:49:42 -0700
Subject: RFR(JDK12/NIO) 8209576: java.nio.file.Files.writeString writes
 garbled UTF-16 instead of UTF-8
In-Reply-To: <5B774098.3090506@oracle.com>
References: <5B774098.3090506@oracle.com>
Message-ID: <5B7742F6.3030705@oracle.com>

+1

On 08/17/2018 02:39 PM, Joe Wang wrote:
> Hi,
>
> Please review a fix for a condition where a code conversion was skipped incorrectly resulting in a wrong byte array being written into the file.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209576/webrev/
>
> Thanks,
> Joe
>


From peter.levart at gmail.com  Sat Aug 18 09:30:40 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 18 Aug 2018 11:30:40 +0200
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <ff31a1b0-ed3b-6775-0ee3-2af310f52cba@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <bddd2a43-668f-467f-dbd1-ab7cc8ddcaf1@gmail.com>
 <6bfce6b0-377b-4fa3-3955-06c11f80f372@oracle.com>
 <bfd4e09d-74ee-e3ab-c557-4fa54bc2c7bd@oracle.com>
 <2a0d7718-8365-e274-9ab5-3f46f7a0fb80@oracle.com>
 <CY4PR18MB132052257787D6F11E5D4164833D0@CY4PR18MB1320.namprd18.prod.outlook.com>
 <ff31a1b0-ed3b-6775-0ee3-2af310f52cba@oracle.com>
Message-ID: <87274d57-3a91-cd86-3c04-97d306a07bb6@gmail.com>

Hi Mandy,

On 08/17/2018 05:20 PM, mandy chung wrote:
> Hi Peter, Jason, Joe,
>
> Thanks for the pointers.? I have missed the use of
> serialPersistentFields (thanks to Peter for calling this out).? I read
> the javadoc and serialization spec but that didn't come clearly to me.
> It'd be good to include an example in the javadoc (will file a JBS 
> issue).
>
> W.r.t. the package-private API to set the cause in EIIE [1], yes it's
> needed and it's done in webrev.01.? Let me redo the
> readObject/writeObject part and send a new webrev.
>
> Mandy
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.01/src/java.base/share/classes/java/lang/Throwable.java.sdiff.html 
>

I think it would be nicer to keep all the logic in one place 
(EIIE.readObject()) and make Throwable.setCause() plain unconditional 
setter. For example:

void readObject(....

 ??? Throwable exception = ...
 ??? if (getCause() == null && exception != null) {
 ??? ??? setCause(exception);
 ??? }


Regards, Peter

>
> On 8/17/18 8:05 AM, Jason Mehrens wrote:
>> Hi Mandy,
>>
>> This what we were doing in the past and has examples of removing
>> fields with expected tests: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html 
>> >
>> However, this case is a little different because it actually
>> disallows subsequent initCause.? I would assume that will get tricky
>> if you deserialize the old binary form in a newer JDK because we
>> would have to jump through some hoops to update null to the cause
>> exception.
>>
>> Jason
>>


From amaembo at gmail.com  Sun Aug 19 09:17:33 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 19 Aug 2018 16:17:33 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <55f690c9-f21b-ee9d-aa30-f838b2da7257@gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <CAE+3fjZ09G4307tT70cOHada9iWED5UwCLJ36Fr8rfuxR9MNcw@mail.gmail.com>
 <55f690c9-f21b-ee9d-aa30-f838b2da7257@gmail.com>
Message-ID: <CAE+3fjbcBAiOUB9E3KNaOW_gYG8egLGh5C+ey0hAFQMs14ExfA@mail.gmail.com>

Hello, Peter!

Yes, I would be happy, though see also Roger note.

> Regarding the code, I only have one comment about the naming of the last
parameter: "finisher"

Sounds reasonable, renamed to "merger".

> ...and one comment about handling of IDENTITY_FINISH

I think this would complicate the code unnecessarily adding unpleasant
unchecked casts and more branches. I think that returning non-identity
finisher while reporting IDENTITY_FINISH characteristic is a contract
violation. See, for example, that the existing collectingAndThen collector
relies on the finisher implementation just like I do. It simply uses
downstream.finisher().andThen(finisher)
even if finisher is identity.

With best regards,
Tagir Valeev.

On Tue, Aug 7, 2018 at 3:08 PM Peter Levart <peter.levart at gmail.com> wrote:

> Hi Tagir,
>
> Unless you have already got a sponsor (can't remember if somebody already
> offered you a sponsorship), I can volunteer.
>
> Regarding the code, I only have one comment about the naming of the last
> parameter: "finisher". To avoid confusion, it would be good to name it
> differently from the Collector's functions. "finisher" and "combiner" are
> already taken by Collector API. You describe the parameter in javadoc as
> "the function which merges two results into the single one". So what about
> "merger" or "result[s]Merger" ?
>
> ...and one comment about handling of IDENTITY_FINISH: You correctly remove
> IDENTITY_FINISH from the resulting collector's characteristics, but you
> don't honor the IDENTITY_FINISH characteristics of the two parameter
> collectors. It should work nevertheless, but suppose some "sloppy
> programmed" collector doesn't bother to return the identity function when
> it announces that it has IDENTITY_FINISH characteristic...
>
> Regards, Peter
>
>
> On 08/07/2018 07:52 AM, Tagir Valeev wrote:
>
> Ping! Could you please review and sponsor this changeset?
> I updated version tag from since 11 to since 12:http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r2/
>
> Thanks in advance!
>
> With best regards,
> Tagir Valeev.
>
> On Thu, Jun 21, 2018 at 11:33 AM Tagir Valeev <amaembo at gmail.com> <amaembo at gmail.com> wrote:
>
>
> Please review and sponsor:
> https://bugs.openjdk.java.net/browse/JDK-8205461http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
>
> See also previous discussion thread at [1]. It seems that we did not reach
> the final conclusion about the collector name, so in this review it's still
> named as "pairing" (proposed by me). Other name proposals:
>
> bisecting - by Paul Sandoz (sounds like input is split by two parts like
> in partitioningBy, which is not the case)
> tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical
> operation, while our collector is symmetrical)
> duplex(ing) - by Jacob Glickman (well, probably ok?)
> bifurcate - by James Laskey (or bifurcating?)
> replicator - by James Laskey (as in DNA)
> replicating - by Peter Levart
> fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked
> Wikipedia [2], does not look like suitable)
> distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac;
> but common meaning of "distributing" is different)
> tapping - by Kirk Pepperdine (I have no associations; Google images shows
> some acupuncture procedures)
> split - by Kirk Pepperdine (may be confused with Spliterator)
> unzipping - by John Rose
> biMapping - by Zheka Kozlov (but he also suggests to change signature
> which is unnecessary)
> toBoth - by Peter Levart (but usually toXyz shows target container like
> toArray/toList/toSet, but there's not "Both" container)
> collectionToBothAndThen - by Zheka Kozlov (but too long)
> collectingToBoth - by Zheka Kozlov
> collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a little
> bit repititive?)
> biCollecting - by Zheka Kozlov
> expanding - by Paul Sandoz (doesn't sound very descriptive to me)
> forking - by Victor Williams Stafusa da Silva (could be thought that
> something is parallelized as forking is usually something connected to
> parallel computations)
>
> I think that it's better to concentrate not on the "splitting" part (each
> element is passed to two collectors), but on the "joining" part (results of
> two collectors are combined together). So my preference now is "merging" or
> "combining". If limiting the selection to the suggested options I'd prefer
> "duplexing" or "bifurcating" or to stay with my original version "pairing".
> Of course original Stream API author voices have more weight here, so if
> you insist on particular version, I will follow.
>
> By the way looking into CollectorsTest.java I found some minor things to
> cleanup:
> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced
> with simple `.map(mapper)` and `.flatMap(mapper)` respectively
> 2. In many methods redundant `throws ReflectiveOperationException` is
> declared while exception is never thrown
> 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks useless as
> `map` is already of `Map<Boolean, D>` type, so this check is always false
> (we would never enter this method if it's true). Similarly `if
> (!List.class.isAssignableFrom(value.getClass()))`
> 4. Deprecated `clazz.newInstance()` is used
> 5. Test named `testGroupubgByWithReducing` should be renamed to
> `testGroupingByWithReducing`
>
> Should I fix some or all of these issues? As separate changeset or within
> this one?
>
> With best regards,
> Tagir Valeev.
>
> [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html
> [2] https://en.wikipedia.org/wiki/Fan-out
>
>
>

From amaembo at gmail.com  Sun Aug 19 09:24:44 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 19 Aug 2018 16:24:44 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
Message-ID: <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>

Hello, Brian!

> Of the three phases, teeing is the most important and least obvious, so
> I think something that includes that in the name is going to be
> helpful.  Perhaps "teeingAndThen" is more evocative and not totally
> unwieldy.

Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.

> > By the way looking into CollectorsTest.java I found some minor things to
> > cleanup:
> > 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
> > simple `.map(mapper)` and `.flatMap(mapper)` respectively
> Does IntelliJ have an inspection for eliminating such locutions?

Sure, that's how I found them. Well, I took the liberty to fix these two things.

> > 2. In many methods redundant `throws ReflectiveOperationException` is
> > declared while exception is never thrown
> For test code where a significant fraction of test cases are going to
> throw something, we often do this, since its easier to just uniformly
> tag such methods rather than thinking about which test methods actually
> throw the exception and which don't.  So I think this is harmless
> (though cleaning it up is harmless too.)

I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
leave them as is for now.

> You may want to optimize the EnumSet mechanics for the case where
> neither collector has interesting characteristics.

Added a special case when reported characteristics for either of
collectors are empty or IDENTITY_FINISH only.
I think this should be a common case.

The updated webrev is posted here (along with Peter suggestion to
rename finisher to merger):
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
Also copyright year is updated

With best regards,
Tagir Valeev

From vyom.tewari at oracle.com  Sun Aug 19 11:51:59 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Sun, 19 Aug 2018 17:21:59 +0530
Subject: RFR: JDK-8176553 LdapContext follows referrals infinitely ignoring
 set limit
Message-ID: <a88d2aa1-4b51-beff-5fed-22357188919b@oracle.com>

Hi,

Please review the below? code change.

Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html

bugid??? : https://bugs.openjdk.java.net/browse/JDK-8176553

Our? all internal tests are clean, this patch is contributed by Jan 
Kalina(Redhat).

Thanks,

Vyom


From peter.levart at gmail.com  Mon Aug 20 07:06:56 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 20 Aug 2018 09:06:56 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
Message-ID: <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>

Hi Tagir,

I think this looks very good. It just needs a CSR. Will you file it?

Regards, Peter

On 08/19/2018 11:24 AM, Tagir Valeev wrote:
> Hello, Brian!
>
>> Of the three phases, teeing is the most important and least obvious, so
>> I think something that includes that in the name is going to be
>> helpful.  Perhaps "teeingAndThen" is more evocative and not totally
>> unwieldy.
> Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.
>
>>> By the way looking into CollectorsTest.java I found some minor things to
>>> cleanup:
>>> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
>>> simple `.map(mapper)` and `.flatMap(mapper)` respectively
>> Does IntelliJ have an inspection for eliminating such locutions?
> Sure, that's how I found them. Well, I took the liberty to fix these two things.
>
>>> 2. In many methods redundant `throws ReflectiveOperationException` is
>>> declared while exception is never thrown
>> For test code where a significant fraction of test cases are going to
>> throw something, we often do this, since its easier to just uniformly
>> tag such methods rather than thinking about which test methods actually
>> throw the exception and which don't.  So I think this is harmless
>> (though cleaning it up is harmless too.)
> I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
> leave them as is for now.
>
>> You may want to optimize the EnumSet mechanics for the case where
>> neither collector has interesting characteristics.
> Added a special case when reported characteristics for either of
> collectors are empty or IDENTITY_FINISH only.
> I think this should be a common case.
>
> The updated webrev is posted here (along with Peter suggestion to
> rename finisher to merger):
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
> Also copyright year is updated
>
> With best regards,
> Tagir Valeev


From vyom.tewari at oracle.com  Mon Aug 20 07:24:11 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Mon, 20 Aug 2018 12:54:11 +0530
Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/
In-Reply-To: <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com>
References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com>
 <DC4F9209-8A0A-4CBE-89B9-97603DD5E408@oracle.com>
 <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com>
Message-ID: <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com>

Hi Chris,

Latest webrev(.02) looks good to me. One minor comment i will suggest 
you to? expand "setContext" as you did for other JNDI tests.

Thanks,

Vyom


On Friday 10 August 2018 02:34 PM, Chris Yin wrote:
> Sorry... another minor revision to handle @Override line and imports place, new webrev as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8208542/webrev.02/
>
> Regards,
> Chris
>
>> On 8 Aug 2018, at 2:51 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>
>> Minor revision to address javadoc, initContext() expansion, vararg etc. webrev as below, thanks
>>
>> http://cr.openjdk.java.net/~xyin/8208542/webrev.01/
>>
>> Regards,
>> Chris
>>
>>> On 31 Jul 2018, at 2:39 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>
>>> Please review the changes to add 4 JNDI tests to com/sun/jndi/dns/ListTests/ in OpenJDK, thanks
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208542
>>> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/
>>>
>>> Regards,
>>> Chris


From amaembo at gmail.com  Mon Aug 20 08:48:25 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 20 Aug 2018 15:48:25 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
Message-ID: <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>

Hello!

A CSR is created:
https://bugs.openjdk.java.net/browse/JDK-8209685
(this is my first CSR, hopefully I did it correctly)

With best regards,
Tagir Valeev.
On Mon, Aug 20, 2018 at 2:06 PM Peter Levart <peter.levart at gmail.com> wrote:
>
> Hi Tagir,
>
> I think this looks very good. It just needs a CSR. Will you file it?
>
> Regards, Peter
>
> On 08/19/2018 11:24 AM, Tagir Valeev wrote:
>
> Hello, Brian!
>
> Of the three phases, teeing is the most important and least obvious, so
> I think something that includes that in the name is going to be
> helpful.  Perhaps "teeingAndThen" is more evocative and not totally
> unwieldy.
>
> Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.
>
> By the way looking into CollectorsTest.java I found some minor things to
> cleanup:
> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
> simple `.map(mapper)` and `.flatMap(mapper)` respectively
>
> Does IntelliJ have an inspection for eliminating such locutions?
>
> Sure, that's how I found them. Well, I took the liberty to fix these two things.
>
> 2. In many methods redundant `throws ReflectiveOperationException` is
> declared while exception is never thrown
>
> For test code where a significant fraction of test cases are going to
> throw something, we often do this, since its easier to just uniformly
> tag such methods rather than thinking about which test methods actually
> throw the exception and which don't.  So I think this is harmless
> (though cleaning it up is harmless too.)
>
> I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
> leave them as is for now.
>
> You may want to optimize the EnumSet mechanics for the case where
> neither collector has interesting characteristics.
>
> Added a special case when reported characteristics for either of
> collectors are empty or IDENTITY_FINISH only.
> I think this should be a common case.
>
> The updated webrev is posted here (along with Peter suggestion to
> rename finisher to merger):
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
> Also copyright year is updated
>
> With best regards,
> Tagir Valeev
>
>

From xu.y.yin at oracle.com  Mon Aug 20 09:28:58 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Mon, 20 Aug 2018 17:28:58 +0800
Subject: [12] RFR 8200151: Add 8 JNDI tests to
 com/sun/jndi/dns/ConfigTests/
In-Reply-To: <3afd41a3-ef1c-7092-6d37-66bfc23081a7@oracle.com>
References: <9FD6703A-49E8-41D8-B527-8D0D09726EB0@oracle.com>
 <c34ea8df-8feb-e52a-ded9-5f8ab0dae7b2@oracle.com>
 <8961A4DD-5119-46BD-B2B4-A3162302CAF7@oracle.com>
 <7fc8c142-1047-84b3-a009-d06e39dc0e92@oracle.com>
 <A0464C7B-5214-4AB0-9446-9C2B96FD0CD9@oracle.com>
 <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com>
 <3afd41a3-ef1c-7092-6d37-66bfc23081a7@oracle.com>
Message-ID: <E30A91A4-CD8F-461C-9A93-C1910796F955@oracle.com>

Hi, Roger

Sorry for the late response since I was on vacation and thank you for the comments, inline and update webrev as below

http://cr.openjdk.java.net/~xyin/8200151/webrev.03/

> On 11 Aug 2018, at 1:47 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Chris,
> 
> There seems to be a lot of repetition in tests that could be combined.
> For example, the RecursiveDefault, RecursiveTrue, and RecursiveFalse tests should be a
> single test that is invoked 3 times, (multiple @run lines) with an argument to say which case to test.
> There would be fewer files and less code to maintain.
> 
> The same goes for AuthDefault, AuthTrue and AuthFalse.

Thanks, fixed as you suggested, minor change in DNSTestUtils to support it

> 
> Why is PortUnreachable added to the ProblemList and also included in the Change set.
> It would cleaner to treat it separately if it can't be fixed as part of adding these new tests.

Thank you for checking this, there is a platform specified known issue on macOS which caused PortUnreachable failure, but it?s unrelated to JNDI feature, and test working well on other platforms, so I add it to problemlist to exclude the test for macOS only, feel free to let me know if it?s not suitable, I could just remove the test here for now

> 
> Consider using java.time.Instant and Duration for the Timeout test;
> it will print nicer and has some handy methods.

Sure, changed as you suggested, thanks

Regards,
Chris

> 
> Regards, Roger
> 
> 
> On 8/10/18 5:15 AM, Chris Yin wrote:
>> Minor revision to address testbase javadoc, initContext() expansion, @Override line and imports place, new webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8200151/webrev.02/
>> 
>> Regards,
>> Chris
>> 
>>> On 30 Jul 2018, at 5:08 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Thank you, Vyom
>>> 
>>> Regards,
>>> Chris
>>> 
>>>> On 30 Jul 2018, at 5:06 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Latest code looks good to me.
>>>> 
>>>> Thanks,
>>>> 
>>>> Vyom
>>>> 
>>>> On Friday 27 July 2018 01:12 PM, Chris Yin wrote:
>>>>> Hi, Vyom
>>>>> 
>>>>> Thank a lot for your review and comments, inline and update new webrev as below, thanks
>>>>> 
>>>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.01/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.01/>
>>>>> 
>>>>> 
>>>>>> On 26 Jul 2018, at 5:27 PM, vyom tewari <vyom.tewari at oracle.com <mailto:vyom.tewari at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> Thanks for writing the tests overall code looks good to me, below are few minor comments.
>>>>>> 
>>>>>> 1`-> Fix tag order, my Netbeans always complains :) .
>>>>> Fixed, thanks
>>>>> 
>>>>>> 2->  you make AuthRecursiveBase class as public but i can not see it is being used outside,  i will suggest you to give the default access if possible.
>>>>> Sure, changed it to default access now
>>>>> 
>>>>>> 3-> AuthTrue.java, change the message as follows
>>>>>> 
>>>>>> "Got exception as expected : " -> "Got expected exception: ?;
>>>>> Fixed
>>>>> 
>>>>>> 
>>>>>> 4-> PortUnreachable.java , any specific reason for 1000ms or you just choose random value ? Please don't hard-code this specific value  create a  constant and use it . If possible put some comment why we choose 1 second, this will help in debugging if this test fails intermittently in future.
>>>>> Sure, I created a constant ?THRESHOLD' for it, 1000ms will be used as a threshold value for this test, normally the request should fail very quick (in a few ms), but consider to different platform and test machine performance, we used an acceptable threshold here, some comments added to it in the code too, thanks
>>>>> 
>>>>>> 5-> Timeout.java, do you really need to set the env using "DNSTestUtils.initEnv" ?
>>>>>> 
>>>>>> I see, this test is not using the DNSServer and other environments variables which were set by "DNSTestUtils.initEnv()" or i am missing something.
>>>>> Actually, it?s indeed not necessary, just set very few default value such as ?Context.INITIAL_CONTEXT_FACTORY? in the test code should be fine, but I may still want to keep the test consistency, then we could have better maintainability for those tests. Sorry, I forgot to refactor this test with testbase (actually, its not necessary too, but guess the consistent style and shared base/methods will make the test easy to read and maintain, refactored this test and PortUnreachable.java now)
>>>>> 
>>>>> Regards,
>>>>> Chris
>>>>> 
>>>>>> Thanks,
>>>>>> Vyom
>>>>>> 
>>>>>> On Wednesday 25 July 2018 02:41 PM, Chris Yin wrote:
>>>>>>> Please review the changes to add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ in OpenJDK, due to known issue 7164518, PortUnreachable.java will be problem list for 'macosx-all', thanks
>>>>>>> 
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151> <https://bugs.openjdk.java.net/browse/JDK-8200151 <https://bugs.openjdk.java.net/browse/JDK-8200151>>
>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/> <http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ <http://cr.openjdk.java.net/%7Exyin/8200151/webrev.00/>>
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Chris
> 


From volker.simonis at gmail.com  Mon Aug 20 10:22:16 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 20 Aug 2018 12:22:16 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
Message-ID: <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>

On Fri, Aug 17, 2018 at 7:25 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 08/17/2018 05:12 PM, Volker Simonis wrote:
>> The offending code in Console_md.c looks as follows:
>>
>> #define ECHO    8
>>
>> JNIEXPORT jboolean JNICALL
>> Java_java_io_Console_echo(...) {
>>
>>     jboolean old;
>>     ...
>>     old = (tio.c_lflag & ECHO);
>>     ...
>>     return old;
>> }
>>
>> The intention of this code is to return "true" if the ECHO flag was
>> set but it really returns the value of ECHO (which is defined as '8'
>> in a system header).
>>
>> The question now is, if a Java SE compatible VM guarantees that any
>> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
>> and only a zero valued jboolean will be interpreted as "JNI_FALSE"?
>>
>> Or, the other way round, is the normalization performed by the HotSpot
>> result handlers necessary (i.e. enforced by the specification) or just
>> a convenience to fix broken code like the above from Console.echo()?
>
> I think this is intentional aftermath of boolean value normalization:
>   https://bugs.openjdk.java.net/browse/JDK-8161720
>

OMG - I'm getting old :)

Thanks for the link to JDK-8161720! Funny enough I was one of the
reviewers of JDK-8161720 and almost exactly two years ago I already
asked the exactly same question [1]:

"And I have a question about JNI: is it only a convention that JNI
functions should return JNI_TRUE/JNI_FALSE or is this required by the
specification?"

Zoltan answered to that question by citing an excerpt from the JNI
Programmer's Guide & Specification [2]:

"A |jboolean| is an 8-bit unsigned C type that can store values from 0
to 255. The value 0 corresponds to the constant |JNI_FALSE|, and the
values from 1 to 255 correspond to |JNI_TRUE|."

But the "JNI Programmer's Guide & Specification" is from 1999 and it
only contains the cited sentence in its "Traps and Pitfalls" section
and not in the "Specification" part. The latest JNI Specification [3]
doesn't seem to contain such a rule.

So to summarize, my current view on this topic is:
 - JNI functions returning a jboolean are only allowed to return
JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
 - to code in Java_java_io_Console_echo() should be fixed (as
confirmed by Sherman later in this thread)
 - normalization of native, off-heap 8-bit values to Java booleans as
currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
only for convenience to simply access to off-heap data in Unsafe, (2)
to implement better Java/Native integration in projects like Panama
and (3) to fix legacy JNI code which was developed under the
assumption that the advice in the "JNI Programmer's Guide &
Specification" book is specification relevant.

Do you agree?

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024192.html
[2] https://web.archive.org/web/20120626012047/http://java.sun.com/docs/books/jni/html/pitfalls.html#30066
[3] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html

> So, Java_java_io_Console_echo looks broken and needs to be fixed, by e.g.:
>
> -   old = (tio.c_lflag & ECHO);
> +   old = (tio.c_lflag & ECHO) != 0;
>
> Thanks,
> -Aleksey
>

From chris.hegarty at oracle.com  Mon Aug 20 10:49:13 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 Aug 2018 11:49:13 +0100
Subject: RFR: JDK-8176553 LdapContext follows referrals infinitely
 ignoring set limit
In-Reply-To: <a88d2aa1-4b51-beff-5fed-22357188919b@oracle.com>
References: <a88d2aa1-4b51-beff-5fed-22357188919b@oracle.com>
Message-ID: <29AAA659-69E8-4CE9-99BF-DEB6666C1D77@oracle.com>


> On 19 Aug 2018, at 12:51, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi,
> 
> Please review the below  code change.
> 
> Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html
> 
> bugid    : https://bugs.openjdk.java.net/browse/JDK-8176553
> 
> Our  all internal tests are clean, this patch is contributed by Jan Kalina(Redhat).

I think the source change is good.

How much trouble is it to write a test?

-Chris.


From claes.redestad at oracle.com  Mon Aug 20 10:56:10 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Aug 2018 12:56:10 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <aee7d6dc-4805-d033-9db5-97d70ee642ab@oracle.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
 <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
 <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>
 <aee7d6dc-4805-d033-9db5-97d70ee642ab@oracle.com>
Message-ID: <0be4f903-7415-53a4-9306-cb53f33ab16b@oracle.com>

Hi Mandy,


On 2018-08-17 19:07, mandy chung wrote:
>
>
> On 8/17/18 7:38 AM, Peter Levart wrote:
>>
>>
>> On 08/17/2018 04:32 PM, Claes Redestad wrote:
>>> Hi Peter,
>>>
>>> On 2018-08-17 16:04, Peter Levart wrote:
>>>> Hi Claes,
>>>>
>>>> Nice trick.
>
> +1

thanks!

>
>>>> You made MethodType(s) and WeakEntry(s) holding them equal, 
>>>> respecting the equals()/hashCode() contract. When WeakEntry looses 
>>>> the referent it is left equal to itself only, which is enough for 
>>>> expunging it from map.
>>>
>>> Good summary. Do you think we need a few comments to spell out these 
>>> intricacies?
>>
>> Yes, perhaps just pointers from the two equals() methods to each 
>> other, explaining that they are actually one method which is split 
>> into two unrelated classes.
>
> It'd be worth to document this as javadoc of these two equals methods
> (that's probably what you are thinking).

While this could be an @implNote in the javadoc, I think as this is an 
internal implementation detail with a private type (WeakEntry) (that 
doesn't leak) we are better off just adding this as a code comment on 
MethodType#equals:

diff -r a34087e2b440 
src/java.base/share/classes/java/lang/invoke/MethodType.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon 
Aug 20 12:30:38 2018 +0200
+++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon 
Aug 20 12:46:20 2018 +0200
@@ -786,6 +786,9 @@
 ????? * @param x object to compare
 ????? * @see Object#equals(Object)
 ????? */
+??? // This implementation may also return true if x is a WeakEntry 
containing
+??? // a method type that is equal to this. This is an internal 
implementation
+??? // detail to allow for faster method type lookups.
 ???? @Override
 ???? public boolean equals(Object x) {
 ???????? if (this == x) {
@@ -1350,6 +1353,12 @@
 ???????????????? hashcode = key.hashCode();
 ???????????? }

+??????????? /**
+???????????? * This implementation returns true both if {@code obj} is 
another
+???????????? * {@code WeakEntry} whose referent is equals to this 
referent, but also
+???????????? * if {@code obj} is equals to the referent directly. This 
allows
+???????????? * lookups to be made without wrapping in a {@code WeakEntry}.
+???????????? */
 ???????????? @Override
 ???????????? public boolean equals(Object obj) {
 ???????????????? Object mine = get();

/Claes

From peter.levart at gmail.com  Mon Aug 20 11:31:01 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 20 Aug 2018 13:31:01 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <0be4f903-7415-53a4-9306-cb53f33ab16b@oracle.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
 <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
 <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>
 <aee7d6dc-4805-d033-9db5-97d70ee642ab@oracle.com>
 <0be4f903-7415-53a4-9306-cb53f33ab16b@oracle.com>
Message-ID: <ea575bfd-f977-af62-0839-34a004414894@gmail.com>

Hi Claes,

That's ok. You could also add @see tag to WeakEntry.equals pointing to 
MethodType.equals. The other way around is not possible, but you could 
spell-out the same: "See also WeakEntry.equals()"

Regards, Peter

On 08/20/2018 12:56 PM, Claes Redestad wrote:
>
>>> Yes, perhaps just pointers from the two equals() methods to each 
>>> other, explaining that they are actually one method which is split 
>>> into two unrelated classes.
>>
>> It'd be worth to document this as javadoc of these two equals methods
>> (that's probably what you are thinking).
>
> While this could be an @implNote in the javadoc, I think as this is an 
> internal implementation detail with a private type (WeakEntry) (that 
> doesn't leak) we are better off just adding this as a code comment on 
> MethodType#equals:
>
> diff -r a34087e2b440 
> src/java.base/share/classes/java/lang/invoke/MethodType.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon 
> Aug 20 12:30:38 2018 +0200
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon 
> Aug 20 12:46:20 2018 +0200
> @@ -786,6 +786,9 @@
> ????? * @param x object to compare
> ????? * @see Object#equals(Object)
> ????? */
> +??? // This implementation may also return true if x is a WeakEntry 
> containing
> +??? // a method type that is equal to this. This is an internal 
> implementation
> +??? // detail to allow for faster method type lookups.
> ???? @Override
> ???? public boolean equals(Object x) {
> ???????? if (this == x) {
> @@ -1350,6 +1353,12 @@
> ???????????????? hashcode = key.hashCode();
> ???????????? }
>
> +??????????? /**
> +???????????? * This implementation returns true both if {@code obj} 
> is another
> +???????????? * {@code WeakEntry} whose referent is equals to this 
> referent, but also
> +???????????? * if {@code obj} is equals to the referent directly. 
> This allows
> +???????????? * lookups to be made without wrapping in a {@code 
> WeakEntry}.
> +???????????? */
> ???????????? @Override
> ???????????? public boolean equals(Object obj) {
> ???????????????? Object mine = get();
>
> /Claes


From claes.redestad at oracle.com  Mon Aug 20 12:20:04 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 20 Aug 2018 14:20:04 +0200
Subject: RFR: 8209633: Avoid creating WeakEntry wrappers when looking up
 cached MethodType
In-Reply-To: <ea575bfd-f977-af62-0839-34a004414894@gmail.com>
References: <a24d3b20-a2ba-35fc-29fa-0d66173b6057@oracle.com>
 <473c4282-a3a0-5e34-7682-b466ae2cc125@gmail.com>
 <7b13f9a4-63b3-6a4e-6b19-3a42f1656046@oracle.com>
 <2127b0fb-f522-a0cc-8a55-368454c1b6ac@gmail.com>
 <aee7d6dc-4805-d033-9db5-97d70ee642ab@oracle.com>
 <0be4f903-7415-53a4-9306-cb53f33ab16b@oracle.com>
 <ea575bfd-f977-af62-0839-34a004414894@gmail.com>
Message-ID: <be55aa0e-42e7-cb15-9003-532d603e677a@oracle.com>

Ok, will do.


On 2018-08-20 13:31, Peter Levart wrote:
> Hi Claes,
>
> That's ok. You could also add @see tag to WeakEntry.equals pointing to 
> MethodType.equals. The other way around is not possible, but you could 
> spell-out the same: "See also WeakEntry.equals()"
>


From jai.forums2013 at gmail.com  Mon Aug 20 12:26:07 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 20 Aug 2018 17:56:07 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
Message-ID: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>

Hello everyone,

I'm requesting a review of a documentation change which was discussed in
a recent thread[1][2]. Here's an initial proposed draft, for a better
documentation of Arrays.asList method:

??? /**
???? * Returns a fixed-size list backed by the specified array. The passed
???? * array is held as a reference in the returned list. Any subsequent
???? * changes made to the array contents will be visible in the returned
???? * list. Similarly any changes that happen in the returned list will
???? * also be visible in the array. The returned list is serializable and
???? * implements {@link RandomAccess}.
???? *
???? * <p>The returned list can be changed only in certain ways. Operations
???? * like {@code add}, {@code remove}, {@code clear} and other such, that
???? * change the size of the list aren't allowed. Operations like
???? * {@code replaceAll}, {@code set}, that change the elements in the list
???? * are permitted.
???? *
???? * <p>This method acts as bridge between array-based and
collection-based
???? * APIs, in combination with {@link Collection#toArray}.
???? *
???? * @apiNote
???? * This method also provides a convenient way to create a fixed-size
???? * list initialized to contain several elements:
???? * <pre>
???? *???? List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe",
"Curly");
???? * </pre>
???? *
???? * <p>The returned list throws a {@link
UnsupportedOperationException} for
???? * operations that aren't permitted. Certain implementations of the
returned
???? * list might choose to throw the exception only if the call to such
methods
???? * results in an actual change, whereas certain other
implementations may
???? * always throw the exception when such methods are called.
???? *
???? * @param <T> the class of the objects in the array
???? * @param a the array by which the list will be backed
???? * @return a list view of the specified array
???? */
??? @SafeVarargs
??? @SuppressWarnings("varargs")
??? public static <T> List<T> asList(T... a)


I've edited some of the existing documentation of that method, moved
some existing parts into @apiNote and added additional parts both to the
spec as well as the @apiNote. For a complete reference of what's
changed, I've also attached a patch of this change.

P.S: Is there a specific (make) target that I can run to make sure
changes like this one haven't caused any javadoc generation issues? I
typically run just "make" and did it this time too, but I'm not sure it
parses and generates the javadocs (couldn't find it in the generated
exploded build image).

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html

[2] https://bugs.openjdk.java.net/browse/JDK-7033681

-Jaikiran
-------------- next part --------------
diff -r cdffba164671 src/java.base/share/classes/java/util/Arrays.java
--- a/src/java.base/share/classes/java/util/Arrays.java	Mon Aug 20 10:04:00 2018 +0200
+++ b/src/java.base/share/classes/java/util/Arrays.java	Mon Aug 20 17:53:21 2018 +0530
@@ -4288,18 +4288,35 @@
     // Misc
 
     /**
-     * Returns a fixed-size list backed by the specified array.  (Changes to
-     * the returned list "write through" to the array.)  This method acts
-     * as bridge between array-based and collection-based APIs, in
-     * combination with {@link Collection#toArray}.  The returned list is
-     * serializable and implements {@link RandomAccess}.
-     *
-     * <p>This method also provides a convenient way to create a fixed-size
+     * Returns a fixed-size list backed by the specified array. The passed
+     * array is held as a reference in the returned list. Any subsequent
+     * changes made to the array contents will be visible in the returned
+     * list. Similarly any changes that happen in the returned list will
+     * also be visible in the array. The returned list is serializable and
+     * implements {@link RandomAccess}.
+     *
+     * <p>The returned list can be changed only in certain ways. Operations
+     * like {@code add}, {@code remove}, {@code clear} and other such, that
+     * change the size of the list aren't allowed. Operations like
+     * {@code replaceAll}, {@code set}, that change the elements in the list
+     * are permitted.
+     *
+     * <p>This method acts as bridge between array-based and collection-based
+     * APIs, in combination with {@link Collection#toArray}.
+     *
+     * @apiNote
+     * This method also provides a convenient way to create a fixed-size
      * list initialized to contain several elements:
      * <pre>
      *     List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe", "Curly");
      * </pre>
      *
+     * <p>The returned list throws a {@link UnsupportedOperationException} for
+     * operations that aren't permitted. Certain implementations of the returned
+     * list might choose to throw the exception only if the call to such methods
+     * results in an actual change, whereas certain other implementations may
+     * always throw the exception when such methods are called.
+     *
      * @param <T> the class of the objects in the array
      * @param a the array by which the list will be backed
      * @return a list view of the specified array

From federico.peralta at gmail.com  Mon Aug 20 14:45:08 2018
From: federico.peralta at gmail.com (Federico Peralta Schaffner)
Date: Mon, 20 Aug 2018 11:45:08 -0300
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
Message-ID: <CA+zu5pp6VgqDmja0-oYvB2-okX+GD8u_SD7=dnPhsKyic=y0kA@mail.gmail.com>

Hi,

I think this is a very good addition to the Collectors API. Whereas somehow
specific, it will come in very handy when needed.

But the name... well, honestly, teeingAndThen doesn't tell me anything from
the perspective of an user of the API. What is 'teeing'? What does 'tee'
actually mean? Or perhaps... Ah! They've finally added teeing to the API!
Great! Now let's check what 'tee' actually means for these guys. I'm not
sure, maybe it sounds a little bit too technical, or too
implementation-specific to me.

If I forget for a minute about the 'how' and focus on the 'what', I see
that the operation either delegates to two collectors and then merges the
results, or that it is aggregating two collectors. So, if it's not too late
for new proposals, here are my 2 options:

 - delegateAndMerge (not gerund, but I think that delegatingAndMerging ends
up beeing too long and too gerund-ish)

 - aggregating

(I admit that I've though about these names once I read the comments of the
operations/classes in the linked resources).

Thanks,
fps.-





El lun., 20 ago. 2018 a las 10:49, Tagir Valeev (<amaembo at gmail.com>)
escribi?:

> Hello!
>
> A CSR is created:
> https://bugs.openjdk.java.net/browse/JDK-8209685
> (this is my first CSR, hopefully I did it correctly)
>
> With best regards,
> Tagir Valeev.
> On Mon, Aug 20, 2018 at 2:06 PM Peter Levart <peter.levart at gmail.com>
> wrote:
> >
> > Hi Tagir,
> >
> > I think this looks very good. It just needs a CSR. Will you file it?
> >
> > Regards, Peter
> >
> > On 08/19/2018 11:24 AM, Tagir Valeev wrote:
> >
> > Hello, Brian!
> >
> > Of the three phases, teeing is the most important and least obvious, so
> > I think something that includes that in the name is going to be
> > helpful.  Perhaps "teeingAndThen" is more evocative and not totally
> > unwieldy.
> >
> > Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.
> >
> > By the way looking into CollectorsTest.java I found some minor things to
> > cleanup:
> > 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced
> with
> > simple `.map(mapper)` and `.flatMap(mapper)` respectively
> >
> > Does IntelliJ have an inspection for eliminating such locutions?
> >
> > Sure, that's how I found them. Well, I took the liberty to fix these two
> things.
> >
> > 2. In many methods redundant `throws ReflectiveOperationException` is
> > declared while exception is never thrown
> >
> > For test code where a significant fraction of test cases are going to
> > throw something, we often do this, since its easier to just uniformly
> > tag such methods rather than thinking about which test methods actually
> > throw the exception and which don't.  So I think this is harmless
> > (though cleaning it up is harmless too.)
> >
> > I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
> > leave them as is for now.
> >
> > You may want to optimize the EnumSet mechanics for the case where
> > neither collector has interesting characteristics.
> >
> > Added a special case when reported characteristics for either of
> > collectors are empty or IDENTITY_FINISH only.
> > I think this should be a common case.
> >
> > The updated webrev is posted here (along with Peter suggestion to
> > rename finisher to merger):
> > http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
> > Also copyright year is updated
> >
> > With best regards,
> > Tagir Valeev
> >
> >
>

From shade at redhat.com  Mon Aug 20 14:55:19 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Aug 2018 16:55:19 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
Message-ID: <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>

On 08/20/2018 12:22 PM, Volker Simonis wrote:
> So to summarize, my current view on this topic is:
>  - JNI functions returning a jboolean are only allowed to return
> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.

Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is
(JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for
convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are
"convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which
seems to invite interpretation that all 8 bits are usable.

John says [2]:

"The JNI documents specify that, at least for returning values from native methods, a Java boolean
(T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe
-128..127) and then testing against zero."

...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I
can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that
also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly?


>  - to code in Java_java_io_Console_echo() should be fixed (as
> confirmed by Sherman later in this thread)

Yes, that's a bug waiting to happen anyway.


>  - normalization of native, off-heap 8-bit values to Java booleans as
> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
> only for convenience to simply access to off-heap data in Unsafe, (2)
> to implement better Java/Native integration in projects like Panama
> and (3) to fix legacy JNI code which was developed under the
> assumption that the advice in the "JNI Programmer's Guide &
> Specification" book is specification relevant.

Yes, the intent seems to be what you describe. But see above about the spec.


-Aleksey

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types
[2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html
[3] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4


From jason.greene at redhat.com  Mon Aug 20 15:14:11 2018
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 20 Aug 2018 10:14:11 -0500
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
Message-ID: <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com>


> On Aug 20, 2018, at 9:55 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> So to summarize, my current view on this topic is:
>> - JNI functions returning a jboolean are only allowed to return
>> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
> 
> Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is
> (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for
> convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are
> "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which
> seems to invite interpretation that all 8 bits are usable.
> 
> John says [2]:
> 
> "The JNI documents specify that, at least for returning values from native methods, a Java boolean
> (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe
> -128..127) and then testing against zero."
> 
> ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I
> can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that
> also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly?



IMO departing from C semantics (non-zero = TRUE, zero = false) offers little gain and will likely just lead to hard to catch bugs. Even if the JNI developer knows the rules, it will be quite easy for surprises to show up. For example, a developer might assume a library call always returns 1, and wire it straight to a boolean. If this assumption is broken (a condition not taken into account, or future behavioral differences), then it could quickly turn into a lot of wasted time and effort.  The only way to deal with it is to safeguard every call with a conversion macro/function, and it?s easy to envision that being forgotten.

-Jason 

From adinn at redhat.com  Mon Aug 20 15:18:37 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 20 Aug 2018 16:18:37 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com>
 <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>
 <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>
Message-ID: <50ed4716-b76e-6557-1146-03084776c160@redhat.com>

Hi Alan,

Round 4:

I have redrafted the JEP and updated the implementation in the light of
your last feedback:

  JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851

  Formatted JEP: http://openjdk.java.net/jeps/8207851

  New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.04/

n.b. the webrev is against the latest jdkdev head.

n.b.b. there is only one change additional to those which respond to
your feedback (all documented below). I had to redefine the x86 status
bits used to tag presence of clflushopt and clwb insns (in class
VM_Version). The ones I originally bagged were claimed by some new
vector (VAES?) API -- which borked things spectacularly until  worked ut
what was going on.

> On 06/08/18 10:29, Alan Bateman wrote:

>> The current iteration, to introduce new MapMode values, is not too bad
>> but it makes me wonder if we could avoid new modes altogether by
>> detecting that the file is backed by NVM. Is there a fcntl cmd or some
>> other syscall that can be used to detect this? I'm asking because it
>> would open the potential to discuss limiting the API changes to just
>> MappedByteBuffer.

I have not made this change for reasons outlined in my previous post.

>> In the draft JEP then the Summary, Goals, Non-Goals, Success Metrics,
>> and Motivation sections read well. The Description section is very wordy
>> and includes a lot of implementation detail that I assume will be
>> removed before it is submitted (my guess is that it can be distilled
>> down to a couple of paragraphs). As a comparison, the API surface in JEP
>> 337 is much larger but we were able to reduce the text down to a few
>> paragraphs. The Testing sectioning highlights the challenges and reminds
>> me that we have several features that will need maintainers to
>> continuously test to ensure that a feature doesn't bit rot (SCTP and the
>> proposed APIs for RDMA sockets are in the same boat).

The JEP is now slim and trim, omitting all details of the implementation.

>> Are you familiar with BufferPoolMXBean which can be used by management
>> tools to monitor pool of buffers? I'm wondering if we should introduce a
>> new pool for NVM so that it doesn't show up in the "mapped" pool.

I have updated the JEP to require that stats for current persistent
MappedByteBuffer instances (i.e. those mapped with
MapMode.READ_ONLY_PERSISTENT or MapMode.READ_WRITE_PERSISTENT) are
exposed via a new BufferPoolMXBean with name "mapped_persistent".

This is additional to and separate from the bean & associated stats
which currently detail other file-map derived MappedByteBuffer instances.

The JEP requires this new bean to be exposed in the list retrieved by a
call to ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class)

>> - there are residual references to map_persistent in several places

I think I have removed all of them from the code

>> - MappedByteBuffer.force will need to specify IAE

IAE was intended for the case where an attempt was made to map a
PERSISTENT MapMode and the fd turned out not to be for an NVM. It is not
possible to detect this reliably when running on a Linux kernels which
do not implement MAP_SYNC + MAP_SHARED_PRIVATE. So, I changed the API to
return an IOException in all cases, with an embedded error message
indicating the problem as accurately as possible. That means there is no
change to the method's exception signature, rather to the possible
causes for the IOException.

>> - The new methods are missing @since

I think I have added these annotations in all places where they are needed.

>> - I think it would be clearer if MappedByteBuffer.force use "region"
>> rather than "sub-region" as it is used in the context of the buffer, not
>> the original file.

I think I fixed all occurrences.

>> - There will be round of clean up needed to the changes to java.base to
>> get the javadoc and code consistent with the javadoc/code in this area.
>> I assume we'll get back to that when the patch is closer to review.
Sure, happy to do that when we get there.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From volker.simonis at gmail.com  Mon Aug 20 15:37:47 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 20 Aug 2018 17:37:47 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
Message-ID: <CA+3eh10fawjthi5Y7wQnur6o-m6mMnnEz+n3HYG439mgR_qY1g@mail.gmail.com>

On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> So to summarize, my current view on this topic is:
>>  - JNI functions returning a jboolean are only allowed to return
>> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
>
> Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is
> (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for
> convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are
> "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which
> seems to invite interpretation that all 8 bits are usable.
>
> John says [2]:
>
> "The JNI documents specify that, at least for returning values from native methods, a Java boolean
> (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe
> -128..127) and then testing against zero."
>
> ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I
> can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that
> also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly?
>

Yes, you're right - there's no exact documentation for neither of the
two possible interpretations. A colleague just pointed me to the
definition of invokestatic in the JVMS [4] which has the following
sentence:

"If the native method returns a value, the return value of the
platform-dependent code is converted in an implementation-dependent
way to the return type of the native method and pushed onto the
operand stack."

But then again, it has this unfortunate "implementation-dependent"
which can be interpreted either way :(

[4] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic

>
>>  - to code in Java_java_io_Console_echo() should be fixed (as
>> confirmed by Sherman later in this thread)
>
> Yes, that's a bug waiting to happen anyway.
>
>
>>  - normalization of native, off-heap 8-bit values to Java booleans as
>> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
>> only for convenience to simply access to off-heap data in Unsafe, (2)
>> to implement better Java/Native integration in projects like Panama
>> and (3) to fix legacy JNI code which was developed under the
>> assumption that the advice in the "JNI Programmer's Guide &
>> Specification" book is specification relevant.
>
> Yes, the intent seems to be what you describe. But see above about the spec.
>
>
> -Aleksey
>
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types
> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html
> [3] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4
>

From vyom.tewari at oracle.com  Mon Aug 20 11:29:43 2018
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Mon, 20 Aug 2018 16:59:43 +0530
Subject: RFR: JDK-8176553 LdapContext follows referrals infinitely
 ignoring set limit
In-Reply-To: <29AAA659-69E8-4CE9-99BF-DEB6666C1D77@oracle.com>
References: <a88d2aa1-4b51-beff-5fed-22357188919b@oracle.com>
 <29AAA659-69E8-4CE9-99BF-DEB6666C1D77@oracle.com>
Message-ID: <5B7AA627.7090301@oracle.com>



On 8/20/2018 4:19 PM, Chris Hegarty wrote:
>> On 19 Aug 2018, at 12:51, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the below  code change.
>>
>> Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html
>>
>> bugid    : https://bugs.openjdk.java.net/browse/JDK-8176553
>>
>> Our  all internal tests are clean, this patch is contributed by Jan Kalina(Redhat).
> I think the source change is good.
>
> How much trouble is it to write a test?
We need "LDAP" server, that is why i did not included the test with this 
patch. I tested locally with "apacheds" and code is working as expected.
Thanks,
Vyom
>
> -Chris.
>


From rednaxelafx at gmail.com  Mon Aug 20 16:09:48 2018
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Mon, 20 Aug 2018 09:09:48 -0700
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+3eh10fawjthi5Y7wQnur6o-m6mMnnEz+n3HYG439mgR_qY1g@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <CA+3eh10fawjthi5Y7wQnur6o-m6mMnnEz+n3HYG439mgR_qY1g@mail.gmail.com>
Message-ID: <CA+cQ+tTUsxpuCVxxxTFiunpFQNF0kpe099fW7TugFZV_Z7v0ig@mail.gmail.com>

Hi guys,

Haha this is fun. I actually hit this issue the hard way and had to tweak a
bit of my code to accommodate that: I had to return a jint from a function
that I wanted to return a jbool at first:
http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp

- Kris

On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis <volker.simonis at gmail.com>
wrote:

> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <shade at redhat.com>
> wrote:
> > On 08/20/2018 12:22 PM, Volker Simonis wrote:
> >> So to summarize, my current view on this topic is:
> >>  - JNI functions returning a jboolean are only allowed to return
> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
> >
> > Now *I* am having trouble seeing where exactly the JNI spec says the
> domain of jboolean is
> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following
> definition is provided for
> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the
> domain, because those are
> > "convenience" defines. And "Description" in the table says jboolean is
> "unsigned 8 bits", which
> > seems to invite interpretation that all 8 bits are usable.
> >
> > John says [2]:
> >
> > "The JNI documents specify that, at least for returning values from
> native methods, a Java boolean
> > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating
> to a byte (0..255 or maybe
> > -128..127) and then testing against zero."
> >
> > ...which is what I am looking for, but I cannot find the "JNI document"
> that actually says that. I
> > can see the idea of that in JVMS [3], but that seems to only apply to
> on-heap booleans, does that
> > also extend to jboolean's? Maybe John can point out the JNI document
> where it is said explicitly?
> >
>
> Yes, you're right - there's no exact documentation for neither of the
> two possible interpretations. A colleague just pointed me to the
> definition of invokestatic in the JVMS [4] which has the following
> sentence:
>
> "If the native method returns a value, the return value of the
> platform-dependent code is converted in an implementation-dependent
> way to the return type of the native method and pushed onto the
> operand stack."
>
> But then again, it has this unfortunate "implementation-dependent"
> which can be interpreted either way :(
>
> [4]
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic
>
> >
> >>  - to code in Java_java_io_Console_echo() should be fixed (as
> >> confirmed by Sherman later in this thread)
> >
> > Yes, that's a bug waiting to happen anyway.
> >
> >
> >>  - normalization of native, off-heap 8-bit values to Java booleans as
> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
> >> only for convenience to simply access to off-heap data in Unsafe, (2)
> >> to implement better Java/Native integration in projects like Panama
> >> and (3) to fix legacy JNI code which was developed under the
> >> assumption that the advice in the "JNI Programmer's Guide &
> >> Specification" book is specification relevant.
> >
> > Yes, the intent seems to be what you describe. But see above about the
> spec.
> >
> >
> > -Aleksey
> >
> > [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types
> > [2]
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html
> > [3]
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4
> >
>

From volker.simonis at gmail.com  Mon Aug 20 16:28:48 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 20 Aug 2018 18:28:48 +0200
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+cQ+tTUsxpuCVxxxTFiunpFQNF0kpe099fW7TugFZV_Z7v0ig@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <CA+3eh10fawjthi5Y7wQnur6o-m6mMnnEz+n3HYG439mgR_qY1g@mail.gmail.com>
 <CA+cQ+tTUsxpuCVxxxTFiunpFQNF0kpe099fW7TugFZV_Z7v0ig@mail.gmail.com>
Message-ID: <CA+3eh12WWYALmHXvmJC7aMDPWDFq+Ha6k8RTFfj4X8p=CgRDNw@mail.gmail.com>

On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:
> Hi guys,
>
> Haha this is fun. I actually hit this issue the hard way and had to tweak a
> bit of my code to accommodate that: I had to return a jint from a function
> that I wanted to return a jbool at first:
> http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp
>

Interesting, but I think that mis-behavior should have been fixed
meanwhile by the infamous "Better byte behavior" change [1] (which was
a security fix, so you won't find too much information about it).

So maybe you can remove your workaround and comment now :)

[1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72

> - Kris
>
> On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <shade at redhat.com>
>> wrote:
>> > On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> >> So to summarize, my current view on this topic is:
>> >>  - JNI functions returning a jboolean are only allowed to return
>> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
>> >
>> > Now *I* am having trouble seeing where exactly the JNI spec says the
>> > domain of jboolean is
>> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following
>> > definition is provided for
>> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the
>> > domain, because those are
>> > "convenience" defines. And "Description" in the table says jboolean is
>> > "unsigned 8 bits", which
>> > seems to invite interpretation that all 8 bits are usable.
>> >
>> > John says [2]:
>> >
>> > "The JNI documents specify that, at least for returning values from
>> > native methods, a Java boolean
>> > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating
>> > to a byte (0..255 or maybe
>> > -128..127) and then testing against zero."
>> >
>> > ...which is what I am looking for, but I cannot find the "JNI document"
>> > that actually says that. I
>> > can see the idea of that in JVMS [3], but that seems to only apply to
>> > on-heap booleans, does that
>> > also extend to jboolean's? Maybe John can point out the JNI document
>> > where it is said explicitly?
>> >
>>
>> Yes, you're right - there's no exact documentation for neither of the
>> two possible interpretations. A colleague just pointed me to the
>> definition of invokestatic in the JVMS [4] which has the following
>> sentence:
>>
>> "If the native method returns a value, the return value of the
>> platform-dependent code is converted in an implementation-dependent
>> way to the return type of the native method and pushed onto the
>> operand stack."
>>
>> But then again, it has this unfortunate "implementation-dependent"
>> which can be interpreted either way :(
>>
>> [4]
>> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic
>>
>> >
>> >>  - to code in Java_java_io_Console_echo() should be fixed (as
>> >> confirmed by Sherman later in this thread)
>> >
>> > Yes, that's a bug waiting to happen anyway.
>> >
>> >
>> >>  - normalization of native, off-heap 8-bit values to Java booleans as
>> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
>> >> only for convenience to simply access to off-heap data in Unsafe, (2)
>> >> to implement better Java/Native integration in projects like Panama
>> >> and (3) to fix legacy JNI code which was developed under the
>> >> assumption that the advice in the "JNI Programmer's Guide &
>> >> Specification" book is specification relevant.
>> >
>> > Yes, the intent seems to be what you describe. But see above about the
>> > spec.
>> >
>> >
>> > -Aleksey
>> >
>> > [1]
>> > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types
>> > [2]
>> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html
>> > [3]
>> > https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4
>> >

From huizhe.wang at oracle.com  Mon Aug 20 17:14:28 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 20 Aug 2018 10:14:28 -0700
Subject: RFR(JDK12/NIO) 8209576: java.nio.file.Files.writeString writes
 garbled UTF-16 instead of UTF-8
In-Reply-To: <5B7742F6.3030705@oracle.com>
References: <5B774098.3090506@oracle.com> <5B7742F6.3030705@oracle.com>
Message-ID: <5B7AF6F4.2060308@oracle.com>

Thanks Sherman!

All tests in core were passed. The patch is now pushed.

-Joe

On 8/17/18, 2:49 PM, Xueming Shen wrote:
> +1
>
> On 08/17/2018 02:39 PM, Joe Wang wrote:
>> Hi,
>>
>> Please review a fix for a condition where a code conversion was 
>> skipped incorrectly resulting in a wrong byte array being written 
>> into the file.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209576
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209576/webrev/
>>
>> Thanks,
>> Joe
>>
>

From aph at redhat.com  Mon Aug 20 17:23:49 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Aug 2018 18:23:49 +0100
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com>
Message-ID: <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com>

On 08/20/2018 04:14 PM, Jason Greene wrote:

> IMO departing from C semantics (non-zero = TRUE, zero = false)
> offers little gain and will likely just lead to hard to catch
> bugs. Even if the JNI developer knows the rules, it will be quite
> easy for surprises to show up. For example, a developer might assume
> a library call always returns 1, and wire it straight to a
> boolean. If this assumption is broken (a condition not taken into
> account, or future behavioral differences), then it could quickly
> turn into a lot of wasted time and effort.

It's tricky, though: a C implementation could silently truncate a
value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing
that a JVM can do about it: there's literally no way to know.  It's
pretty much unfixable from our end.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From rednaxelafx at gmail.com  Mon Aug 20 18:16:34 2018
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Mon, 20 Aug 2018 11:16:34 -0700
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <CA+3eh12WWYALmHXvmJC7aMDPWDFq+Ha6k8RTFfj4X8p=CgRDNw@mail.gmail.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <CA+3eh10fawjthi5Y7wQnur6o-m6mMnnEz+n3HYG439mgR_qY1g@mail.gmail.com>
 <CA+cQ+tTUsxpuCVxxxTFiunpFQNF0kpe099fW7TugFZV_Z7v0ig@mail.gmail.com>
 <CA+3eh12WWYALmHXvmJC7aMDPWDFq+Ha6k8RTFfj4X8p=CgRDNw@mail.gmail.com>
Message-ID: <CA+cQ+tQ1=2rTMngWsvY3N956VJpFGdQOio8Tgs9TkLdVpfaz_g@mail.gmail.com>

Thanks Volker! I hadn't been following new development much and this is
great!
I just checked the latest HS sources [1] and my old code is still there.
I'll prepare a webrev to remove that workaround code.

Thanks,
Kris

[1]:
http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1/c1_Runtime1.cpp#l1380

On Mon, Aug 20, 2018 at 9:28 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok <rednaxelafx at gmail.com>
> wrote:
> > Hi guys,
> >
> > Haha this is fun. I actually hit this issue the hard way and had to
> tweak a
> > bit of my code to accommodate that: I had to return a jint from a
> function
> > that I wanted to return a jbool at first:
> > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/
> 8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp
> >
>
> Interesting, but I think that mis-behavior should have been fixed
> meanwhile by the infamous "Better byte behavior" change [1] (which was
> a security fix, so you won't find too much information about it).
>
> So maybe you can remove your workaround and comment now :)
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72
>
> > - Kris
> >
> > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis <volker.simonis at gmail.com
> >
> > wrote:
> >>
> >> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <shade at redhat.com>
> >> wrote:
> >> > On 08/20/2018 12:22 PM, Volker Simonis wrote:
> >> >> So to summarize, my current view on this topic is:
> >> >>  - JNI functions returning a jboolean are only allowed to return
> >> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI
> spcification.
> >> >
> >> > Now *I* am having trouble seeing where exactly the JNI spec says the
> >> > domain of jboolean is
> >> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following
> >> > definition is provided for
> >> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the
> >> > domain, because those are
> >> > "convenience" defines. And "Description" in the table says jboolean is
> >> > "unsigned 8 bits", which
> >> > seems to invite interpretation that all 8 bits are usable.
> >> >
> >> > John says [2]:
> >> >
> >> > "The JNI documents specify that, at least for returning values from
> >> > native methods, a Java boolean
> >> > (T_BOOLEAN) value is converted to the value-set 0..1 by first
> truncating
> >> > to a byte (0..255 or maybe
> >> > -128..127) and then testing against zero."
> >> >
> >> > ...which is what I am looking for, but I cannot find the "JNI
> document"
> >> > that actually says that. I
> >> > can see the idea of that in JVMS [3], but that seems to only apply to
> >> > on-heap booleans, does that
> >> > also extend to jboolean's? Maybe John can point out the JNI document
> >> > where it is said explicitly?
> >> >
> >>
> >> Yes, you're right - there's no exact documentation for neither of the
> >> two possible interpretations. A colleague just pointed me to the
> >> definition of invokestatic in the JVMS [4] which has the following
> >> sentence:
> >>
> >> "If the native method returns a value, the return value of the
> >> platform-dependent code is converted in an implementation-dependent
> >> way to the return type of the native method and pushed onto the
> >> operand stack."
> >>
> >> But then again, it has this unfortunate "implementation-dependent"
> >> which can be interpreted either way :(
> >>
> >> [4]
> >> https://docs.oracle.com/javase/specs/jvms/se10/html/
> jvms-6.html#jvms-6.5.invokestatic
> >>
> >> >
> >> >>  - to code in Java_java_io_Console_echo() should be fixed (as
> >> >> confirmed by Sherman later in this thread)
> >> >
> >> > Yes, that's a bug waiting to happen anyway.
> >> >
> >> >
> >> >>  - normalization of native, off-heap 8-bit values to Java booleans as
> >> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is
> (1)
> >> >> only for convenience to simply access to off-heap data in Unsafe, (2)
> >> >> to implement better Java/Native integration in projects like Panama
> >> >> and (3) to fix legacy JNI code which was developed under the
> >> >> assumption that the advice in the "JNI Programmer's Guide &
> >> >> Specification" book is specification relevant.
> >> >
> >> > Yes, the intent seems to be what you describe. But see above about the
> >> > spec.
> >> >
> >> >
> >> > -Aleksey
> >> >
> >> > [1]
> >> > https://docs.oracle.com/javase/8/docs/technotes/
> guides/jni/spec/types.html#primitive_types
> >> > [2]
> >> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-
> dev/2016-August/024263.html
> >> > [3]
> >> > https://docs.oracle.com/javase/specs/jvms/se10/html/
> jvms-2.html#jvms-2.3.4
> >> >
>

From igor.ignatyev at oracle.com  Mon Aug 20 18:29:58 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 20 Aug 2018 11:29:58 -0700
Subject: RFR(XXS) : 8209740 : typo in test/lib/jtreg/SkippedException.java
Message-ID: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html
> 1 line changed: 0 ins; 0 del; 1 mod; 

Hi all,

could you please review this trivial fix for the typo in SkippedException.java ? Thank Martin B for reporting the typo.

JBS: https://bugs.openjdk.java.net/browse/JDK-8209740
webrev: http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html

Thanks,
-- Igor


 



From brent.christian at oracle.com  Mon Aug 20 18:42:48 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 20 Aug 2018 11:42:48 -0700
Subject: RFR(XXS) : 8209740 : typo in test/lib/jtreg/SkippedException.java
In-Reply-To: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com>
References: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com>
Message-ID: <f9983dbe-10cc-6fc0-078a-4e8fb06a709b@oracle.com>

Looks fine.

-Brent

On 8/20/18 11:29 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html
>> 1 line changed: 0 ins; 0 del; 1 mod;
> 
> Hi all,
> 
> could you please review this trivial fix for the typo in SkippedException.java ? Thank Martin B for reporting the typo.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209740
> webrev: http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html
> 
> Thanks,
> -- Igor
> 

From jason.greene at redhat.com  Mon Aug 20 19:25:32 2018
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 20 Aug 2018 14:25:32 -0500
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com>
 <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com>
Message-ID: <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com>


> On Aug 20, 2018, at 12:23 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 08/20/2018 04:14 PM, Jason Greene wrote:
> 
>> IMO departing from C semantics (non-zero = TRUE, zero = false)
>> offers little gain and will likely just lead to hard to catch
>> bugs. Even if the JNI developer knows the rules, it will be quite
>> easy for surprises to show up. For example, a developer might assume
>> a library call always returns 1, and wire it straight to a
>> boolean. If this assumption is broken (a condition not taken into
>> account, or future behavioral differences), then it could quickly
>> turn into a lot of wasted time and effort.
> 
> It's tricky, though: a C implementation could silently truncate a
> value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing
> that a JVM can do about it: there's literally no way to know.  It's
> pretty much unfixable from our end.

OK but in that case the C developer can see its an unsigned char, and their
compiler is likely to throw an overflow warning. Granted, it?s also true that 
int is a more common return value than unsigned char.

-Jason


From david.holmes at oracle.com  Tue Aug 21 01:06:44 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Aug 2018 11:06:44 +1000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
 <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>
 <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>
Message-ID: <ded6b65d-a968-a1cc-ca6b-906a9c28f72c@oracle.com>

Hi Mandy,

A correction on my part ...

On 17/08/2018 8:22 AM, David Holmes wrote:
> On 17/08/2018 1:18 AM, mandy chung wrote:
>>
>>
>> On 8/15/18 11:00 PM, David Holmes wrote:
>>> Hi Mandy,
>>>
>>> Not a review - sorry :)
>>>
>>> On 16/08/2018 7:46 AM, mandy chung wrote:
>>>> ExceptionInInitializerError(Throwable cause) sets the detail message 
>>>> to null.? It'd be helpful to include a detail message rather than null
>>>> as in Throwable(Throwable cause) that constructs a new throwable
>>>> with a default message cause==null ? null : cause.toString().
>>>>
>>>> This would help troubleshooting of writing new bootstrap methods
>>>> where VM currently asserts non-null linkage error message [1] where
>>>> there are other solutions such as constructing the message in
>>>> the VM or removing the assert.
>>>
>>> I think that's just a bug in the VM code making inappropriate 
>>> assumptions! There shouldn't have to be a detail message, especially 
>>> in a wrapping exception like ExceptionInInitializerError! It only 
>>> gets thrown because some other exception was thrown, there's really 
>>> no more detail for the EIIE itself. Promoting the cause's detail 
>>> message to be the detail message of the EIIE just seems wrong to me.
>>
>> I think even VM removes the assert, I don't see how EIIE includes
>> the detail message is wrong?? It's consistent with the
>> Throwable(Throwable cause) constructor.
> 
> I think it is wrong because the message is not that of the EIIE but that 
> of the original exception.
> 
> If EIIE must have a detail message then that should just be something 
> explicit like:
> 
> Caused by <cause exception type> : <cause detail message>

This is of course what you actually propose by using cause.toString() - 
for some reason I was thinking you were just using the cause's detail 
message as the EIIE detail message. Sorry about that.

I still don't think this change is actually necessary, but it's fine.

Thanks,
David
-----

> Unlike general Throwables that may or may not have a cause, a true EIIE 
> must always have a cause when thrown by the JVM.
> 
> David
> -----
> 
>>> Did this come about through the new code that saves the original 
>>> cause of the EIIE so that it can be reported when the subsequent 
>>> NoClassDefFoundError is thrown due to the class being in the 
>>> erroneous state? (I don't recall if that actually got pushed.)
>>
>> I am not sure but I don't think so.? I ran into this when I develop
>> the bootstrap methods.? I think this is a good EIIE clean up.
>>
>> Mandy

From brian.goetz at oracle.com  Tue Aug 21 01:37:19 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 20 Aug 2018 21:37:19 -0400
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
Message-ID: <de303045-5fc6-69a5-95f1-ed60fd51f706@oracle.com>

I note that the only place that R appears is in the output of the 
merger.? So the "? extends" is not needed there; it can be just 
BiFunction<? super R1, ? super R2, R>.

On 8/20/2018 4:48 AM, Tagir Valeev wrote:
> Hello!
>
> A CSR is created:
> https://bugs.openjdk.java.net/browse/JDK-8209685
> (this is my first CSR, hopefully I did it correctly)
>
> With best regards,
> Tagir Valeev.
> On Mon, Aug 20, 2018 at 2:06 PM Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Tagir,
>>
>> I think this looks very good. It just needs a CSR. Will you file it?
>>
>> Regards, Peter
>>
>> On 08/19/2018 11:24 AM, Tagir Valeev wrote:
>>
>> Hello, Brian!
>>
>> Of the three phases, teeing is the most important and least obvious, so
>> I think something that includes that in the name is going to be
>> helpful.  Perhaps "teeingAndThen" is more evocative and not totally
>> unwieldy.
>>
>> Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.
>>
>> By the way looking into CollectorsTest.java I found some minor things to
>> cleanup:
>> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
>> simple `.map(mapper)` and `.flatMap(mapper)` respectively
>>
>> Does IntelliJ have an inspection for eliminating such locutions?
>>
>> Sure, that's how I found them. Well, I took the liberty to fix these two things.
>>
>> 2. In many methods redundant `throws ReflectiveOperationException` is
>> declared while exception is never thrown
>>
>> For test code where a significant fraction of test cases are going to
>> throw something, we often do this, since its easier to just uniformly
>> tag such methods rather than thinking about which test methods actually
>> throw the exception and which don't.  So I think this is harmless
>> (though cleaning it up is harmless too.)
>>
>> I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
>> leave them as is for now.
>>
>> You may want to optimize the EnumSet mechanics for the case where
>> neither collector has interesting characteristics.
>>
>> Added a special case when reported characteristics for either of
>> collectors are empty or IDENTITY_FINISH only.
>> I think this should be a common case.
>>
>> The updated webrev is posted here (along with Peter suggestion to
>> rename finisher to merger):
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
>> Also copyright year is updated
>>
>> With best regards,
>> Tagir Valeev
>>
>>


From mandy.chung at oracle.com  Tue Aug 21 04:31:08 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 20 Aug 2018 21:31:08 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <ded6b65d-a968-a1cc-ca6b-906a9c28f72c@oracle.com>
References: <6fa016cc-66a2-d18f-a239-eb33fd8cd1d8@oracle.com>
 <a6ee0ebe-2c3c-3f2a-f862-9b67a6ef7274@oracle.com>
 <0f8bc8d2-96b4-aba1-2788-b94fc3dc50e5@oracle.com>
 <78b73852-4ca7-e1fe-38e3-3fd1ae7446d6@oracle.com>
 <ded6b65d-a968-a1cc-ca6b-906a9c28f72c@oracle.com>
Message-ID: <05ff8b8c-b11d-81b9-6363-4a678d3fc463@oracle.com>



On 8/20/18 6:06 PM, David Holmes wrote:
>> If EIIE must have a detail message then that should just be something 
>> explicit like:
>>
>> Caused by <cause exception type> : <cause detail message>
> 
> This is of course what you actually propose by using cause.toString() - 
> for some reason I was thinking you were just using the cause's detail 
> message as the EIIE detail message. Sorry about that.

Yup, the proposed detail message for EIIE(Throwable cause) constructor
will have:
    <cause exception type> : <cause detail message>

> I still don't think this change is actually necessary, but it's fine.

I see it's a small improvement for troubleshooting even people live
without it.

A related but different topic:
    While digging up the exception chaining facility related issue,
I found that the private exception field was removed initially
but added back because of JDK-4385429 [1] that failed to deserialize
since the cause can't be re-initialized.

If I redo the fix for JDK-4385429 (essentially adding the package-
private Throwable::setCause), several other exception types such
as UndeclaredThrowableException and InvocationTargetException
will get the default detail message rather than null.  Anyway,
just to mention that a few other exception types may have
similar change.

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-4385429

> Thanks,
> David

From stuart.marks at oracle.com  Tue Aug 21 05:43:47 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 20 Aug 2018 22:43:47 -0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
Message-ID: <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>

Hi Tagir,

Thanks for working on this. This looks really cool! And thanks Peter for 
agreeing to sponsor it.

I can help out with the CSR. My first bit of advice about the CSR process is to 
hold off until the specification is complete. :-)

I think the intent of the API is fine, but I think some details of the returned 
collector need to be ironed out first.

1. The spec doesn't say what the returned collector's supplier, accumulator, 
combiner, and finisher do. On the one hand, we don't necessarily want to 
describe the actual implementation. On the other hand, we need to specify how 
the thing actually behaves. One can certainly deduce the intended behavior from 
the description, but this really needs to be specified, and it mustn't rely on 
the reader having to derive the required behaviors. Since the actual 
implementation is fairly simple, the spec might end up being rather close to the 
implementation, but that might be unavoidable.

I'm envisioning something like this:

  - supplier: creates a result container that contains result containers 
obtained by calling each collector's supplier

  - accumulator: calls each collector's accumulator with its result container 
and the input element

... and similar for the combiner and finisher functions.

2. Characteristics

  - UNORDERED: should the returned collector be UNORDERED if *either* of the 
provided collectors is UNORDERED? (Current draft says *both*.)

  - CONCURRENT: current draft seems correct

  - IDENTITY_FINISH: clearly not present; perhaps this should be specified

3. Parameter naming

The collector parameters are referred to as "specified collectors" or "supplied 
collectors". Other "higher-order" collectors refer to their underlying 
collectors as "downstream" collectors. I think it would be useful to work the 
"downstream" concept into this collector. This would enable the opening summary 
sentence of the doc to be something like, "Returns a collector that is a 
composite of two downstream collectors" or some such. (But see naming below.)

4. Naming

Sigh, naming is hard, and I know there was a fair amount of discussion in the 
previous thread and earlier in this one, but it seems like there's still some 
dissatisfaction with the name. (And I'm not particularly thrilled with 
teeingAndThen myself.) In a few minutes I've managed to come up with a few more 
names that (mostly) don't seem to have been proposed before, and so here they 
are for your consideration:

  - compound
  - composite
  - conjoined
  - bonded
  - fused
  - duplex

Discussion:

A "composite" evokes function composition; this might be good, though it might 
be odd in that collectors can't be composed in the same way that functions are.

"Compound" might be a useful alternative. In chemistry, two substances are 
combined (or bonded, or fused) to form a single substance, which is a compound.

"Conjoin" seems to adequately describe the structure of the two collectors, but 
it lacks somewhat the connotation of unifying them.

In an earlier discussion, Brian had pushed back on names related to 
split/fork/merge/join since those are currently in use in streams regarding 
splitting of input elements and merging of results. In describing how the 
current proposal differs, he said that elements are "multiplexed" to the 
different collectors. Since we're doing this with two collectors, how about 
"duplex"? (I note that Jacob Glickman also had suggested "duplex".)

s'marks





On 8/20/18 1:48 AM, Tagir Valeev wrote:
> Hello!
> 
> A CSR is created:
> https://bugs.openjdk.java.net/browse/JDK-8209685
> (this is my first CSR, hopefully I did it correctly)
> 
> With best regards,
> Tagir Valeev.
> On Mon, Aug 20, 2018 at 2:06 PM Peter Levart <peter.levart at gmail.com> wrote:
>>
>> Hi Tagir,
>>
>> I think this looks very good. It just needs a CSR. Will you file it?
>>
>> Regards, Peter
>>
>> On 08/19/2018 11:24 AM, Tagir Valeev wrote:
>>
>> Hello, Brian!
>>
>> Of the three phases, teeing is the most important and least obvious, so
>> I think something that includes that in the name is going to be
>> helpful.  Perhaps "teeingAndThen" is more evocative and not totally
>> unwieldy.
>>
>> Ok, sounds acceptable to me. Renamed pairing to teeingAndThen.
>>
>> By the way looking into CollectorsTest.java I found some minor things to
>> cleanup:
>> 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with
>> simple `.map(mapper)` and `.flatMap(mapper)` respectively
>>
>> Does IntelliJ have an inspection for eliminating such locutions?
>>
>> Sure, that's how I found them. Well, I took the liberty to fix these two things.
>>
>> 2. In many methods redundant `throws ReflectiveOperationException` is
>> declared while exception is never thrown
>>
>> For test code where a significant fraction of test cases are going to
>> throw something, we often do this, since its easier to just uniformly
>> tag such methods rather than thinking about which test methods actually
>> throw the exception and which don't.  So I think this is harmless
>> (though cleaning it up is harmless too.)
>>
>> I'm not thinking about this, because my IDE thinks for me :-) Ok, I'll
>> leave them as is for now.
>>
>> You may want to optimize the EnumSet mechanics for the case where
>> neither collector has interesting characteristics.
>>
>> Added a special case when reported characteristics for either of
>> collectors are empty or IDENTITY_FINISH only.
>> I think this should be a common case.
>>
>> The updated webrev is posted here (along with Peter suggestion to
>> rename finisher to merger):
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r3/
>> Also copyright year is updated
>>
>> With best regards,
>> Tagir Valeev
>>
>>

From peter.levart at gmail.com  Tue Aug 21 07:04:08 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 21 Aug 2018 09:04:08 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
Message-ID: <ab1f2171-5c79-e203-e21f-323d1aacd913@gmail.com>

Hi Stuart,

On 08/21/2018 07:43 AM, Stuart Marks wrote:
> 2. Characteristics
>
> ?- UNORDERED: should the returned collector be UNORDERED if *either* 
> of the provided collectors is UNORDERED? (Current draft says *both*.)

I think *both* is the right behavior. If you are collecting:

 ??? teeingAndThen(
 ??? ??? Collectors.toList(),
 ??? ??? Collectors.toSet(),
 ??? ??? Map::entry
 ??? )

...then you might want the returned List part of result to respect 
encounter order regardless of the returned Set part which doesn't.


Regards, Peter


From peter.levart at gmail.com  Tue Aug 21 07:37:22 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 21 Aug 2018 09:37:22 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
Message-ID: <c73a6896-1330-b6e7-82c9-f04161124c18@gmail.com>

I just note that sometimes naming is hard. Not because there would be no 
suitable name to choose from but because there are too many. In such 
situations it becomes apparent that every individual's brain works 
slightly differently. That said, I must admit that teeingAndThen is not 
my favorite either. The "tee" UNIX command is not "symmetrical". It 
interposes itself into the pipeline as a pass-through element (stdin -> 
stdout) and has (one ore more) additional outputs in the form of files. 
The name "tee" comes from T-splitter used in plumbing, where the 
pass-through direction is a straight line (the horizontal on letter T), 
while the additional output is the vertical:

https://en.wikipedia.org/wiki/Piping_and_plumbing_fitting#Tee

Out collector is symmetrical though.

On 08/21/2018 07:43 AM, Stuart Marks wrote:
> a few more names that (mostly) don't seem to have been proposed 
> before, and so here they are for your consideration:
>
> ?- compound
> ?- composite
> ?- conjoined
> ?- bonded
> ?- fused
> ?- duplex
>
> Discussion:
>
> A "composite" evokes function composition; this might be good, though 
> it might be odd in that collectors can't be composed in the same way 
> that functions are.
>
> "Compound" might be a useful alternative. In chemistry, two substances 
> are combined (or bonded, or fused) to form a single substance, which 
> is a compound.
>
> "Conjoin" seems to adequately describe the structure of the two 
> collectors, but it lacks somewhat the connotation of unifying them.
>
> In an earlier discussion, Brian had pushed back on names related to 
> split/fork/merge/join since those are currently in use in streams 
> regarding splitting of input elements and merging of results. In 
> describing how the current proposal differs, he said that elements are 
> "multiplexed" to the different collectors. Since we're doing this with 
> two collectors, how about "duplex"? (I note that Jacob Glickman also 
> had suggested "duplex".) 

My brain likes "duplex".

duplex, duplexing or duplexingAndThen ? I think "duplexing". AndThen 
suffix is not needed. Even if there is a standard Pair class to come in 
the future, overloaded "duplexing" method could be added with no 
ambiguity (mental or javac).

Regards, Peter


From magnus.ihse.bursie at oracle.com  Tue Aug 21 09:31:56 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 21 Aug 2018 11:31:56 +0200
Subject: RFR 8209064: Make intellij support more robust after changes for
 2018.2
In-Reply-To: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>
References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>
Message-ID: <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com>

Hi Maurizio!

Even if this only incidentally relates to the build, please always 
include build-dev when making changes in the "make" directory.

As far as I can understand, your changes looks good. One question: the 
build.xml was previously stored as a "template", and copied to the 
output directory. Now it's left in the source tree. I assume that there 
was no actual transformations or changes made to the template before? So 
that the scripts do not modify the source tree version, that is.

/Magnus

On 2018-08-07 13:21, Maurizio Cimadamore wrote:
> Hi,
> last week I submitted an 'emergency' patch to fix intellij project 
> support after 2018.2 changes. The goal of these changes was to move 
> the build.xml ant file out of the .idea folder, as the IDE no longer 
> supported DOM indexing in such folders (as a result of 
> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
> tweaked the scripts to copy build.xml in the build folder.
>
> Thinking more about this issue, there's a more robust fix possible, 
> which doesn't involve moving files to the build folder (which could be 
> potentially unreliable, depending on how people build the JDK). In 
> fact, the best solution is to leave build.xml where it is, and fix the 
> remaining configuration files to point at it. This allows to revert 
> all changes in the scripts that set up the project configuration 
> (bin/idea.sh for JDK, and make/langtools/build.xml for langtools).
>
> For the langtools project a bit more changes were necessary, given 
> that in langtools we did not have a 'template' folder - and all 
> intellij files were dumped onto the same path. So I had to move the 
> configuration langtools files (all but build.xml) under a new template 
> folder (located under make/langtools/intellij/make) and place 
> build.xml outside it. Then tweak the build.xml script to work off this 
> new template folder. These are all small conceptual changes, but the 
> impact on the webrev is quite biggie (because of file renaming etc.).
>
> I also took the chance to fix some issues with the JDK project ANT 
> configuration (see changes in make/idea/template/workspace.xml), as 
> the last changes did not update the location of the ant file used here 
> - as a result no ant target entries were showing up under the Build menu.
>
> Webrev here:
>
> http://cr.openjdk.java.net/~mcimadamore/8209064/
>
> Cheers
> Maurizio
>


From aph at redhat.com  Tue Aug 21 13:23:32 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Aug 2018 14:23:32 +0100
Subject: Is returning a value != '0' or '1' as jboolean from a JNI
 function legal?
In-Reply-To: <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com>
References: <CA+3eh11uropyw1+q_BV9rtuArW4EfU=-4Dc7DZ4o4++hjJ50Ng@mail.gmail.com>
 <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com>
 <CA+3eh12+kLfYM+KHnq5-iTS5MLYwpm7878Qq_-gkrWNPBVxybA@mail.gmail.com>
 <c554201f-8ffe-7732-b406-f90c8a25d908@redhat.com>
 <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com>
 <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com>
 <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com>
Message-ID: <a463edf5-a4bb-3742-42a2-cd8605fb792e@redhat.com>

On 08/20/2018 08:25 PM, Jason Greene wrote:
> 
>> On Aug 20, 2018, at 12:23 PM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 08/20/2018 04:14 PM, Jason Greene wrote:
>>
>>> IMO departing from C semantics (non-zero = TRUE, zero = false)
>>> offers little gain and will likely just lead to hard to catch
>>> bugs. Even if the JNI developer knows the rules, it will be quite
>>> easy for surprises to show up. For example, a developer might assume
>>> a library call always returns 1, and wire it straight to a
>>> boolean. If this assumption is broken (a condition not taken into
>>> account, or future behavioral differences), then it could quickly
>>> turn into a lot of wasted time and effort.
>>
>> It's tricky, though: a C implementation could silently truncate a
>> value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing
>> that a JVM can do about it: there's literally no way to know.  It's
>> pretty much unfixable from our end.
> 
> OK but in that case the C developer can see its an unsigned char,

It's a jboolean.

> and their compiler is likely to throw an overflow warning.

Mmm, but GCC desn't.

> Granted, it?s also true that int is a more common return value than
> unsigned char.

The function in question is *defined* as returning a jboolean: there's
no doubt about that. The question is whether a C implementation
truncates return values, and you can only see that by reading the
system ABI specification. Not every system documents it: the only way
until recently to find out what GCC on x86 did was to look at the
generated code.

The system ABI is different on different systems: on AArch64 a
jboolean return value is silently truncated, on x86 it isn't. The only
solution is to do what's suggested: make sure that you return
JNI_TRUE/JNI_FALSE (or 1/0).

It's all too horrible even to think about.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mearvk at outlook.com  Tue Aug 21 16:21:44 2018
From: mearvk at outlook.com (mr rupplin)
Date: Tue, 21 Aug 2018 16:21:44 +0000
Subject: JVMInit function call - where is it located the source?
Message-ID: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>

Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:


return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);


This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.  Where is it located?


--


And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok


max


From jonathan.gibbons at oracle.com  Tue Aug 21 16:31:03 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 21 Aug 2018 09:31:03 -0700
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <9de4d04a-bf79-b1e7-3e42-37982e24bc4a@oracle.com>



On 8/21/18 9:21 AM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
>
>
> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
>
>
> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.  Where is it located?
>
>
> --
>
>
> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok
>
>
> max
>
Max,

grep is your friend. Try `grep -r JVMInit src`.

Re: javac.c source file.
You asked this before, on July 20, in an email with the subject line 
"Short Question - About javac.c where is it?".
It was answered back then by Erik Joelsson; I suggest you refer back to 
his answer.

-- Jon

From shade at redhat.com  Tue Aug 21 16:31:17 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 21 Aug 2018 18:31:17 +0200
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <3c32a291-b8a1-df82-ab2c-6da631b4074d@redhat.com>

Hi,

I think you need to freshen up the search-fu: find, grep, and ack (beyondgrep). Without it, you
would find understanding the structure of any large project, OpenJDK included, quite frustrating.

On 08/21/2018 06:21 PM, mr rupplin wrote:
> This is given apparently as a function call that will return an int. However the include
> filejava.h shows no source for this function. Where is it located?
[jdk-jdk] $ ack JVMInit src/
src/java.base/unix/native/libjli/java_md_solinux.c
791:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
800:PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm)

src/java.base/macosx/native/libjli/java_md_macosx.c
885:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
924:void PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm) {

src/java.base/windows/native/libjli/java_md.c
886:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
895:PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm)

src/java.base/share/native/libjli/java.h
189:int JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
202:void     PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm);

src/java.base/share/native/libjli/java.c
341:    return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
529:     * PostJVMInit uses the class name as the application name for GUI purposes,
535:    PostJVMInit(env, appClass, vm);


> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok

[jdk-jdk] $ find src/ -name java.c
src/java.base/share/native/libjli/java.c

-Aleksey



From aph at redhat.com  Tue Aug 21 16:32:20 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Aug 2018 17:32:20 +0100
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
> 
> 
> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
> 
> 
> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From stuart.marks at oracle.com  Tue Aug 21 17:43:34 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 21 Aug 2018 10:43:34 -0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <ab1f2171-5c79-e203-e21f-323d1aacd913@gmail.com>
References: <CAE+3fjYe4xd26zBshShbtwqa57r4j_EL+1TOnrr=D9E8=nWB_g@mail.gmail.com>
 <b1b730f6-d65a-35aa-0b96-cb51e9119133@oracle.com>
 <CAE+3fjZ3Q4fExiQ2pHiivC6BdE1m=VnpdRzFTzKiZzmwsAVOWg@mail.gmail.com>
 <a0c904d4-5275-cedc-77ca-341e91de0ad5@gmail.com>
 <CAE+3fjbCtjW_ZUrbrxL3DrGM1gYWQz+5Jdsdks7DsmAHhrfM=Q@mail.gmail.com>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <ab1f2171-5c79-e203-e21f-323d1aacd913@gmail.com>
Message-ID: <0e5fa215-5d8f-794e-ffb0-514c585f33f5@oracle.com>

On 8/21/18 12:04 AM, Peter Levart wrote:
>> ?- UNORDERED: should the returned collector be UNORDERED if *either* of the 
>> provided collectors is UNORDERED? (Current draft says *both*.)
>
> I think *both* is the right behavior. If you are collecting:
>
> ??? teeingAndThen(
> ??? ??? Collectors.toList(),
> ??? ??? Collectors.toSet(),
> ??? ??? Map::entry
> ??? )
>
> ...then you might want the returned List part of result to respect encounter 
> order regardless of the returned Set part which doesn't.
OK, this makes sense. Seems like it should be "both" then.

s'marks


From huizhe.wang at oracle.com  Tue Aug 21 18:17:16 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 21 Aug 2018 11:17:16 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader on
 a valid input
Message-ID: <5B7C572C.2040308@oracle.com>

Hi,

Please review a patch for a regression that was introduced in JDK 9 b147 
by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK parser 
returns all contiguous character data in a single chunk. After the patch 
then, the parser would return partially if the data is not read 
completely in the current buffer. Before it returns however, it should 
have maintained the state so that it could continue parsing as CDATA for 
the next read. What's missing in the JDK-8158619 therefore was to set 
the state explicitly to CDATA. Without doing so, the parser would 
attempt to read the beginning of the next buffer to determine the state, 
that sometimes (as in this case) could be wrong.

JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/


[1] https://bugs.openjdk.java.net/browse/JDK-8158619

Thanks,
Joe


From lance.andersen at oracle.com  Tue Aug 21 19:01:48 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 21 Aug 2018 15:01:48 -0400
Subject: RFR(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader on
 a valid input
In-Reply-To: <5B7C572C.2040308@oracle.com>
References: <5B7C572C.2040308@oracle.com>
Message-ID: <7C0B544F-69DF-4B03-9F09-4544FB7B6881@oracle.com>

Hi Joe,

The change and test look fine.  I assume the test for 8158619 is still happy :-)

Best
lance


> On Aug 21, 2018, at 2:17 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a patch for a regression that was introduced in JDK 9 b147 by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK parser returns all contiguous character data in a single chunk. After the patch then, the parser would return partially if the data is not read completely in the current buffer. Before it returns however, it should have maintained the state so that it could continue parsing as CDATA for the next read. What's missing in the JDK-8158619 therefore was to set the state explicitly to CDATA. Without doing so, the parser would attempt to read the beginning of the next buffer to determine the state, that sometimes (as in this case) could be wrong.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8158619
> 
> Thanks,
> Joe
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From huizhe.wang at oracle.com  Tue Aug 21 19:36:25 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 21 Aug 2018 12:36:25 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader
 on a valid input
In-Reply-To: <7C0B544F-69DF-4B03-9F09-4544FB7B6881@oracle.com>
References: <5B7C572C.2040308@oracle.com>
 <7C0B544F-69DF-4B03-9F09-4544FB7B6881@oracle.com>
Message-ID: <5B7C69B9.7080805@oracle.com>

Thanks Lance!   Yes, the test for 8158619 passed, as did all other xml 
tests.

Best,
Joe

On 8/21/18, 12:01 PM, Lance Andersen wrote:
> Hi Joe,
>
> The change and test look fine.  I assume the test for 8158619 is still 
> happy :-)
>
> Best
> lance
>
>
>> On Aug 21, 2018, at 2:17 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review a patch for a regression that was introduced in JDK 9 
>> b147 by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK 
>> parser returns all contiguous character data in a single chunk. After 
>> the patch then, the parser would return partially if the data is not 
>> read completely in the current buffer. Before it returns however, it 
>> should have maintained the state so that it could continue parsing as 
>> CDATA for the next read. What's missing in the JDK-8158619 therefore 
>> was to set the state explicitly to CDATA. Without doing so, the 
>> parser would attempt to read the beginning of the next buffer to 
>> determine the state, that sometimes (as in this case) could be wrong.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk12/8209615/webrev/>
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8158619
>>
>> Thanks,
>> Joe
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From mearvk at outlook.com  Tue Aug 21 22:37:30 2018
From: mearvk at outlook.com (mr rupplin)
Date: Tue, 21 Aug 2018 22:37:30 +0000
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>
Message-ID: <SN6PR07MB50221EC9B7C7C47130DA0FA1DA310@SN6PR07MB5022.namprd07.prod.outlook.com>

Thanks.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Andrew Haley <aph at redhat.com>
Sent: Tuesday, August 21, 2018 12:32:20 PM
To: mr rupplin; core-libs-dev at openjdk.java.net
Subject: Re: JVMInit function call - where is it located the source?

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
>
>
> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
>
>
> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mearvk at outlook.com  Wed Aug 22 01:02:16 2018
From: mearvk at outlook.com (mr rupplin)
Date: Wed, 22 Aug 2018 01:02:16 +0000
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <SN6PR07MB50221EC9B7C7C47130DA0FA1DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>,
 <SN6PR07MB50221EC9B7C7C47130DA0FA1DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <SN6PR07MB50221C2A3C139AD9C88BE76CDA300@SN6PR07MB5022.namprd07.prod.outlook.com>

Quickly, where do we look?  I can't seem to find where the "javac" command is called in the C interface.


Where is the java code that runs the parser/compiler?  Ok, thanks gotta run ably.


/mr

________________________________
From: mr rupplin <mearvk at outlook.com>
Sent: Tuesday, August 21, 2018 6:37:30 PM
To: core-libs-dev at openjdk.java.net; Andrew Haley
Subject: Re: JVMInit function call - where is it located the source?

Thanks.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Andrew Haley <aph at redhat.com>
Sent: Tuesday, August 21, 2018 12:32:20 PM
To: mr rupplin; core-libs-dev at openjdk.java.net
Subject: Re: JVMInit function call - where is it located the source?

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
>
>
> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
>
>
> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From david.holmes at oracle.com  Wed Aug 22 01:38:06 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Aug 2018 11:38:06 +1000
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <SN6PR07MB50221C2A3C139AD9C88BE76CDA300@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
 <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>
 <SN6PR07MB50221EC9B7C7C47130DA0FA1DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB50221C2A3C139AD9C88BE76CDA300@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <faf1c933-6085-bd84-bb74-26b578bfe432@oracle.com>

On 22/08/2018 11:02 AM, mr rupplin wrote:
> Quickly, where do we look?  I can't seem to find where the "javac" command is called in the C interface.

javac is just the name of a executable launcher that is built.

See make/launcher/Launcher-jdk.compiler.gmk

> Where is the java code that runs the parser/compiler?  Ok, thanks gotta run ably.

src/jdk.compiler/share/classes/com/sun/tools/javac

David

> 
> /mr
> 
> ________________________________
> From: mr rupplin <mearvk at outlook.com>
> Sent: Tuesday, August 21, 2018 6:37:30 PM
> To: core-libs-dev at openjdk.java.net; Andrew Haley
> Subject: Re: JVMInit function call - where is it located the source?
> 
> Thanks.
> 
> Get Outlook for Android<https://aka.ms/ghei36>
> 
> ________________________________
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, August 21, 2018 12:32:20 PM
> To: mr rupplin; core-libs-dev at openjdk.java.net
> Subject: Re: JVMInit function call - where is it located the source?
> 
> On 08/21/2018 05:21 PM, mr rupplin wrote:
>> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
>>
>>
>> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
>>
>>
>> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.
> 
>>   Where is it located?
> 
> Couldn't you just look?
> 
> src/java.base/unix/native/libjli/java_md_solinux.c:79
> 
>> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok
> 
> It's part of the Java launcher, jexec.c. The easiest way to discover
> this stuff is to run javac in a real C++ debugger.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

From mearvk at outlook.com  Wed Aug 22 01:41:12 2018
From: mearvk at outlook.com (mr rupplin)
Date: Wed, 22 Aug 2018 01:41:12 +0000
Subject: JVMInit function call - where is it located the source?
In-Reply-To: <faf1c933-6085-bd84-bb74-26b578bfe432@oracle.com>
References: <SN6PR07MB5022C53C0BBD888E0EFFAE08DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
 <367a59fb-83a8-25a0-336a-e7ff733d2417@redhat.com>
 <SN6PR07MB50221EC9B7C7C47130DA0FA1DA310@SN6PR07MB5022.namprd07.prod.outlook.com>
 <SN6PR07MB50221C2A3C139AD9C88BE76CDA300@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <faf1c933-6085-bd84-bb74-26b578bfe432@oracle.com>
Message-ID: <SN6PR07MB5022CFCD4FA786EB888A0EADDA300@SN6PR07MB5022.namprd07.prod.outlook.com>

Ok, David.  Great, you did it.

________________________________
From: David Holmes <david.holmes at oracle.com>
Sent: Tuesday, August 21, 2018 9:38:06 PM
To: mr rupplin; core-libs-dev at openjdk.java.net; Andrew Haley
Subject: Re: JVMInit function call - where is it located the source?

On 22/08/2018 11:02 AM, mr rupplin wrote:
> Quickly, where do we look?  I can't seem to find where the "javac" command is called in the C interface.

javac is just the name of a executable launcher that is built.

See make/launcher/Launcher-jdk.compiler.gmk

> Where is the java code that runs the parser/compiler?  Ok, thanks gotta run ably.

src/jdk.compiler/share/classes/com/sun/tools/javac

David

>
> /mr
>
> ________________________________
> From: mr rupplin <mearvk at outlook.com>
> Sent: Tuesday, August 21, 2018 6:37:30 PM
> To: core-libs-dev at openjdk.java.net; Andrew Haley
> Subject: Re: JVMInit function call - where is it located the source?
>
> Thanks.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> ________________________________
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, August 21, 2018 12:32:20 PM
> To: mr rupplin; core-libs-dev at openjdk.java.net
> Subject: Re: JVMInit function call - where is it located the source?
>
> On 08/21/2018 05:21 PM, mr rupplin wrote:
>> Inside java.c there is a JLI_Launch which purports to be the launching or entry point for the JVM.  The last line shows:
>>
>>
>> return JVMInit(&ifn, threadStackSize, argc, argv, mode, what, ret);
>>
>>
>> This is given apparently as a function call that will return an int.  However the include file java.h shows no source for this function.
>
>>   Where is it located?
>
> Couldn't you just look?
>
> src/java.base/unix/native/libjli/java_md_solinux.c:79
>
>> And finally where is the javac.c source file? I'm sure it's been here and now its lost. - ok
>
> It's part of the Java launcher, jexec.c. The easiest way to discover
> this stuff is to run javac in a real C++ debugger.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

From magnus.ihse.bursie at oracle.com  Wed Aug 22 08:57:20 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 22 Aug 2018 10:57:20 +0200
Subject: Adding new IBM extended charsets
In-Reply-To: <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>
References: <OF20780B57.BDD380EA-ON002582C0.0044EDAF-652582C0.0045C303@notes.na.collabserv.com>
 <5B3E4AC8.3070307@oracle.com>
 <OF5ED40FB3.D5317855-ON002582C2.00450370-652582C2.004C8D87@notes.na.collabserv.com>
 <4cba7633-33b7-f29a-fb34-05a06b224057@oracle.com>
 <OF63E18FCB.2749C189-ON002582CD.0041A2BD-652582CD.004BCE3C@notes.na.collabserv.com>
 <5B503D69.6010004@oracle.com>
 <4ed347e6-1e64-5ef6-be48-8d12b0adac6f@oracle.com>
 <OF18BC0820.BD754056-ON002582D4.002FE70C-652582D4.00312604@notes.na.collabserv.com>
 <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>
Message-ID: <6ac872e9-6c1a-9d25-4511-026083c48c5a@oracle.com>

On 2018-08-05 20:38, Alan Bateman wrote:
>
> As regards the way forward then I think we have to put infrastructure 
> into the build to make it easy to allow specific charsets be included 
> or excluded from specific platforms. As things stand, and as have you 
> have found with your updates to the stdcs-<platform> files, the 
> charsets are generated to be included in either java.base or 
> jdk.charsets. We need another input to the configurability to make it 
> possible to include or exclude so that the main stream platforms do 
> not have to include the IBM charsets. There are several details around 
> this, particularly around aliases, but if we can get that done then we 
> have a lot of flexibility. 

And when you are ready to discuss the required build changes, please 
head over to build-dev at openjdk.java.net. ;-)

The build part of the charset handling is less-than-ideal. I hope we can 
find a way to clean this up as well, as part of streamlining the 
included charsets.

/Magnus



From enasser at in.ibm.com  Wed Aug 22 18:19:02 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Wed, 22 Aug 2018 23:49:02 +0530
Subject: Adding new IBM extended charsets
In-Reply-To: <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>
References: <OF20780B57.BDD380EA-ON002582C0.0044EDAF-652582C0.0045C303@notes.na.collabserv.com>
 <5B3E4AC8.3070307@oracle.com>
 <OF5ED40FB3.D5317855-ON002582C2.00450370-652582C2.004C8D87@notes.na.collabserv.com>
 <4cba7633-33b7-f29a-fb34-05a06b224057@oracle.com>
 <OF63E18FCB.2749C189-ON002582CD.0041A2BD-652582CD.004BCE3C@notes.na.collabserv.com>
 <5B503D69.6010004@oracle.com>
 <4ed347e6-1e64-5ef6-be48-8d12b0adac6f@oracle.com>
 <OF18BC0820.BD754056-ON002582D4.002FE70C-652582D4.00312604@notes.na.collabserv.com>
 <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>
Message-ID: <OF1891F3A7.A82EFFFA-ON002582F1.006305E8-652582F1.00649EA9@notes.na.collabserv.com>

Hi Alan,

Thank you for your valuable inputs. I will initiate the discussion with 
ICU4J community to explore the possibility of using ICU4J by resolving the 
compatibility and performance difference so that we can use ICU4J for most 
of the extended charsets and remove them JDK build. As we discussed 
earlier, significant changes are required on ICU4J side to resolve the 
functional and performance difference for JDK to directly consume it and 
hence may be considered as a long term solution.

In the mean time, I can explore the other option you have suggested to 
make the IBM charsets specific to AIX platform and keep optional for other 
platforms by making the make file changes. I will try to create a 
prototype to do the make/src file changes which enable generating IBM 
charsets as a separate module only on AIX platform and keep optional for 
other platforms.

Please let me know if you have any inputs.

Thank you,
Nasser Ebrahim




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Nasser Ebrahim <enasser at in.ibm.com>, 
core-libs-dev at openjdk.java.net, Xueming Shen <xueming.shen at oracle.com>
Date:   08/06/2018 12:08 AM
Subject:        Re: Adding new IBM extended charsets



On 24/07/2018 09:56, Nasser Ebrahim wrote:
Thank you Martin, Sherman and Alan for your valuable inputs. 

I have done some initial analysis on the ICU4J. There are some 
compatibility issues on the ICU4J charsets with JDK charsets but am more 
concerned about its performance as JDK optimization do no exist in that 
implementation. I think we need to work with the ICU4J community to 
resolve those issues before we remove those charsets from JDK.
If you can work with the ICU4J project on these issues then I think we 
have a way forward. An additional issue with their downloads is that they 
target JDK 6 and don't seem to have thought about deploying as modules 
with JDK 9 or newer yet. Their downloads can be used as automatic modules 
but it requires renaming their JAR files due to unusual naming that they 
use to encode the version string. A simple Automatic-Module-Name attribute 
would make it easy for developers to deploy their charset provider on the 
module path, they can still target JDK 6.

As regards the way forward then I think we have to put infrastructure into 
the build to make it easy to allow specific charsets be included or 
excluded from specific platforms. As things stand, and as have you have 
found with your updates to the stdcs-<platform> files, the charsets are 
generated to be included in either java.base or jdk.charsets. We need 
another input to the configurability to make it possible to include or 
exclude so that the main stream platforms do not have to include the IBM 
charsets. There are several details around this, particularly around 
aliases, but if we can get that done then we have a lot of flexibility.  
My personal view is that we should work towards excluding the IBM charsets 
from the main stream platforms, starting with a cull of the EBCDIC 
charsets. If the ICU4J project can get their issues sorted out in a 
similar time frame then it makes for a simple migration story -- the JDK 
includes the standard charsets and many additional charsets. If you need 
others then download the ICU4J charset provider and deploy it on your 
class path or module path.

-Alan




From enasser at in.ibm.com  Wed Aug 22 18:27:21 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Wed, 22 Aug 2018 23:57:21 +0530
Subject: Adding new IBM extended charsets
In-Reply-To: <6ac872e9-6c1a-9d25-4511-026083c48c5a@oracle.com>
References: <OF20780B57.BDD380EA-ON002582C0.0044EDAF-652582C0.0045C303@notes.na.collabserv.com>
 <5B3E4AC8.3070307@oracle.com>
 <OF5ED40FB3.D5317855-ON002582C2.00450370-652582C2.004C8D87@notes.na.collabserv.com>
 <4cba7633-33b7-f29a-fb34-05a06b224057@oracle.com>
 <OF63E18FCB.2749C189-ON002582CD.0041A2BD-652582CD.004BCE3C@notes.na.collabserv.com>
 <5B503D69.6010004@oracle.com>
 <4ed347e6-1e64-5ef6-be48-8d12b0adac6f@oracle.com>
 <OF18BC0820.BD754056-ON002582D4.002FE70C-652582D4.00312604@notes.na.collabserv.com>
 <fae8fc1d-bf38-4b8e-7ae6-7ce2459bcdfc@oracle.com>
 <6ac872e9-6c1a-9d25-4511-026083c48c5a@oracle.com>
Message-ID: <OF874A7EB7.1C19636C-ON002582F1.0064DF39-652582F1.0065619A@notes.na.collabserv.com>

Sure Magnus. Thank you for your suggestion.

Once am ready with the prototype, I will initiate the infrastructure 
related discussion to  build-dev at openjdk.java.net and continue the 
streamlining of the extended charsets related discussion here.

Thank you,
Nasser Ebrahim





From:   Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
To:     Alan Bateman <Alan.Bateman at oracle.com>, Nasser Ebrahim 
<enasser at in.ibm.com>, core-libs-dev at openjdk.java.net, build-dev 
<build-dev at openjdk.java.net>
Date:   08/22/2018 02:27 PM
Subject:        Re: Adding new IBM extended charsets



On 2018-08-05 20:38, Alan Bateman wrote:
>
> As regards the way forward then I think we have to put infrastructure 
> into the build to make it easy to allow specific charsets be included 
> or excluded from specific platforms. As things stand, and as have you 
> have found with your updates to the stdcs-<platform> files, the 
> charsets are generated to be included in either java.base or 
> jdk.charsets. We need another input to the configurability to make it 
> possible to include or exclude so that the main stream platforms do 
> not have to include the IBM charsets. There are several details around 
> this, particularly around aliases, but if we can get that done then we 
> have a lot of flexibility. 

And when you are ready to discuss the required build changes, please 
head over to build-dev at openjdk.java.net. ;-)

The build part of the charset handling is less-than-ideal. I hope we can 
find a way to clean this up as well, as part of streamlining the 
included charsets.

/Magnus







From xu.y.yin at oracle.com  Thu Aug 23 00:55:37 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 23 Aug 2018 08:55:37 +0800
Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/
In-Reply-To: <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com>
References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com>
 <DC4F9209-8A0A-4CBE-89B9-97603DD5E408@oracle.com>
 <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com>
 <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com>
Message-ID: <FD26CE3A-F191-4FF9-BC43-6F4AB51A0F4D@oracle.com>

Thank you, Vyom

Regards,
Chris

> On 20 Aug 2018, at 3:24 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Latest webrev(.02) looks good to me. One minor comment i will suggest you to  expand "setContext" as you did for other JNDI tests.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Friday 10 August 2018 02:34 PM, Chris Yin wrote:
>> Sorry... another minor revision to handle @Override line and imports place, new webrev as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8208542/webrev.02/
>> 
>> Regards,
>> Chris
>> 
>>> On 8 Aug 2018, at 2:51 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Minor revision to address javadoc, initContext() expansion, vararg etc. webrev as below, thanks
>>> 
>>> http://cr.openjdk.java.net/~xyin/8208542/webrev.01/
>>> 
>>> Regards,
>>> Chris
>>> 
>>>> On 31 Jul 2018, at 2:39 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>> 
>>>> Please review the changes to add 4 JNDI tests to com/sun/jndi/dns/ListTests/ in OpenJDK, thanks
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208542
>>>> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/
>>>> 
>>>> Regards,
>>>> Chris
> 


From daniel.fuchs at oracle.com  Thu Aug 23 09:19:59 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 Aug 2018 10:19:59 +0100
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
Message-ID: <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>

Hi Bernd,

Good finding! I agree with the proposed cleanup.
I am always a bit uneasy of touching these classes
as they have a propensity to come back and bite you
from behind when you're not looking ;-)

I have applied your patch and sent it to our test system
for more confidence and everything went well.

I'll happily sponsor your patch.
You did sign the OCA - right?

MfG,

-- daniel

On 11/08/2018 20:31, Bernd Eckenfels wrote:
> Hello,
> 
> while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but not in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level) in the master queries a unused class name (pn) and it can use the method reference instead of Lambda. See patch below.
> 
> There seems to be also a opportunity to use computeIfAbsent in a unrelated method add(Level), not sure if this is wanted, what do you think?
> 
> 
> index dbc27124d33..401c6dc73e0 100644
> --- a/src/java.logging/share/classes/java/util/logging/Level.java
> +++ b/src/java.logging/share/classes/java/util/logging/Level.java
> @@ -610,10 +610,7 @@ public class Level implements java.io.Serializable {
>           }
> 
>           private static void registerWithClassLoader(Level customLevel) {
> -            PrivilegedAction<ClassLoader> pa =
> -                  () -> customLevel.getClass().getClassLoader();
> -            PrivilegedAction<String> pn =  customLevel.getClass()::getName;
> -            final String name = AccessController.doPrivileged(pn);
> +            PrivilegedAction<ClassLoader> pa = customLevel.getClass()::getClassLoader;
>               final ClassLoader cl = AccessController.doPrivileged(pa);
>               CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
>                   .add(customLevel);
> @@ -624,19 +621,10 @@ public class Level implements java.io.Serializable {
>               // the mirroredLevel object is always added to the list
>               // before the custom Level instance
>               KnownLevel o = new KnownLevel(l);
> -            List<KnownLevel> list = nameToLevels.get(l.name);
> -            if (list == null) {
> -                list = new ArrayList<>();
> -                nameToLevels.put(l.name, list);
> -            }
> -            list.add(o);
> -
> -            list = intToLevels.get(l.value);
> -            if (list == null) {
> -                list = new ArrayList<>();
> -                intToLevels.put(l.value, list);
> -            }
> -            list.add(o);
> +            nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
> +                .add(o);
> +            intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
> +                .add(o);
> 
>               // keep the custom level reachable from its class loader
>               // This will ensure that custom level values are not GC'ed
> 
> 
> I am happy if anyone can sponsor this change.
> 
> BTW: I get a synthetic Accessor warning on l.name/value, is this what nestmates will resolve ? is it worth adjusting the modifiers for those fields anyway?
> 
> Gruss
> Bernd
> 


From maurizio.cimadamore at oracle.com  Thu Aug 23 13:21:07 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 23 Aug 2018 14:21:07 +0100
Subject: RFR 8209064: Make intellij support more robust after changes for
 2018.2
In-Reply-To: <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com>
References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>
 <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com>
Message-ID: <f5543acc-22ba-1f01-2ff1-4ab5f2502038@oracle.com>



On 21/08/18 10:31, Magnus Ihse Bursie wrote:
> Hi Maurizio!
>
> Even if this only incidentally relates to the build, please always 
> include build-dev when making changes in the "make" directory.
I will - thanks
>
> As far as I can understand, your changes looks good. One question: the 
> build.xml was previously stored as a "template", and copied to the 
> output directory. Now it's left in the source tree. I assume that 
> there was no actual transformations or changes made to the template 
> before? So that the scripts do not modify the source tree version, 
> that is.
You are correct - the script is not meant to be modified; customized 
properties are injected by the runtime environment - such properties are 
defined in the ant.xml file and that is indeed a template file (so it 
can be customized).

Thanks
Maurizio
>
> /Magnus
>
> On 2018-08-07 13:21, Maurizio Cimadamore wrote:
>> Hi,
>> last week I submitted an 'emergency' patch to fix intellij project 
>> support after 2018.2 changes. The goal of these changes was to move 
>> the build.xml ant file out of the .idea folder, as the IDE no longer 
>> supported DOM indexing in such folders (as a result of 
>> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
>> tweaked the scripts to copy build.xml in the build folder.
>>
>> Thinking more about this issue, there's a more robust fix possible, 
>> which doesn't involve moving files to the build folder (which could 
>> be potentially unreliable, depending on how people build the JDK). In 
>> fact, the best solution is to leave build.xml where it is, and fix 
>> the remaining configuration files to point at it. This allows to 
>> revert all changes in the scripts that set up the project 
>> configuration (bin/idea.sh for JDK, and make/langtools/build.xml for 
>> langtools).
>>
>> For the langtools project a bit more changes were necessary, given 
>> that in langtools we did not have a 'template' folder - and all 
>> intellij files were dumped onto the same path. So I had to move the 
>> configuration langtools files (all but build.xml) under a new 
>> template folder (located under make/langtools/intellij/make) and 
>> place build.xml outside it. Then tweak the build.xml script to work 
>> off this new template folder. These are all small conceptual changes, 
>> but the impact on the webrev is quite biggie (because of file 
>> renaming etc.).
>>
>> I also took the chance to fix some issues with the JDK project ANT 
>> configuration (see changes in make/idea/template/workspace.xml), as 
>> the last changes did not update the location of the ant file used 
>> here - as a result no ant target entries were showing up under the 
>> Build menu.
>>
>> Webrev here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8209064/
>>
>> Cheers
>> Maurizio
>>
>


From claes.redestad at oracle.com  Thu Aug 23 14:09:59 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 Aug 2018 16:09:59 +0200
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
Message-ID: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>

Hi,

it's a tiny startup improvement to rearrange code so that the 
ExpiringCaches used in the FileSystem implementations aren't created if 
they aren't going to be used:

Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8209837

3 fewer classes loaded on bootstrap.

Thanks!

/Claes


From sundararajan.athijegannathan at oracle.com  Thu Aug 23 14:30:44 2018
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 23 Aug 2018 20:00:44 +0530
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
Message-ID: <5B7EC514.30607@oracle.com>

Looks good

-Sundar

On 23/08/18, 7:39 PM, Claes Redestad wrote:
> Hi,
>
> it's a tiny startup improvement to rearrange code so that the 
> ExpiringCaches used in the FileSystem implementations aren't created 
> if they aren't going to be used:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209837
>
> 3 fewer classes loaded on bootstrap.
>
> Thanks!
>
> /Claes
>

From claes.redestad at oracle.com  Thu Aug 23 14:31:44 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 Aug 2018 16:31:44 +0200
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <5B7EC514.30607@oracle.com>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
 <5B7EC514.30607@oracle.com>
Message-ID: <90daafa7-57c6-b9de-7f9b-11d76dccfb6e@oracle.com>


On 2018-08-23 16:30, Sundararajan Athijegannathan wrote:
> Looks good

Thanks, Sundar!

/Claes

From forax at univ-mlv.fr  Thu Aug 23 15:12:19 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 23 Aug 2018 17:12:19 +0200 (CEST)
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
Message-ID: <1806747601.606848.1535037139169.JavaMail.zimbra@u-pem.fr>

Hi Claes,

  useCanonPrefixCache = useCanonCaches ? getBooleanProperty("sun.io.useCanonPrefixCache",false) : false;
can be written
  useCanonPrefixCache = useCanonCaches && getBooleanProperty("sun.io.useCanonPrefixCache",false);

and the name useCanonCaches/useCanonPrefixCache should follow the coding convention USE_CANON_CACHES/USE_CANON_PREFIX_CACHE.

otherwise, looks good !

R?mi

----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 23 Ao?t 2018 16:09:59
> Objet: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap

> Hi,
> 
> it's a tiny startup improvement to rearrange code so that the
> ExpiringCaches used in the FileSystem implementations aren't created if
> they aren't going to be used:
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209837
> 
> 3 fewer classes loaded on bootstrap.
> 
> Thanks!
> 
> /Claes

From chris.hegarty at oracle.com  Thu Aug 23 19:16:02 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 Aug 2018 20:16:02 +0100
Subject: RFR: JDK-8176553 LdapContext follows referrals infinitely
 ignoring set limit
In-Reply-To: <5B7AA627.7090301@oracle.com>
References: <a88d2aa1-4b51-beff-5fed-22357188919b@oracle.com>
 <29AAA659-69E8-4CE9-99BF-DEB6666C1D77@oracle.com>
 <5B7AA627.7090301@oracle.com>
Message-ID: <51B5D10C-E32A-4C2F-9475-01B7CB0D2CA2@oracle.com>


> On 20 Aug 2018, at 12:29, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> On 8/20/2018 4:19 PM, Chris Hegarty wrote:
>>> On 19 Aug 2018, at 12:51, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the below  code change.
>>> 
>>> Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html
>>> 
>>> bugid    : https://bugs.openjdk.java.net/browse/JDK-8176553
>>> 
>>> Our  all internal tests are clean, this patch is contributed by Jan Kalina(Redhat).
>> I think the source change is good.
>> 
>> How much trouble is it to write a test?
> We need "LDAP" server, that is why i did not included the test with this patch. I tested locally with "apacheds" and code is working as expected.

Ok, if there is not suitable test infrastructure to test this, then 
I?m ok with the change as is.

-Chris.


From huizhe.wang at oracle.com  Thu Aug 23 19:27:29 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 23 Aug 2018 12:27:29 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8209873: Typo in =?UTF-8?B?amF2YXgueG1s?=
 =?UTF-8?B?LnZhbGlkYXRpb24uVmFsaWRhdG9yLnZhbGlkYXRl4oCLIGRvY3VtZW50YXRpb24=?=
Message-ID: <5B7F0AA1.5050608@oracle.com>

Hi,

Please review a quick fix for a typo in javax.xml.validation.Validator:

diff --git 
a/src/java.xml/share/classes/javax/xml/validation/Validator.java 
b/src/java.xml/share/classes/javax/xml/validation/Validator.java
--- a/src/java.xml/share/classes/javax/xml/validation/Validator.java
+++ b/src/java.xml/share/classes/javax/xml/validation/Validator.java
@@ -214,7 +214,7 @@
       *
       * @throws IllegalArgumentException
       *      If the {@code Result} type doesn't match the
-     *      {@code Source} type of if the {@code Source}
+     *      {@code Source} type or if the {@code Source}
       *      is an XML artifact that the implementation cannot
       *      validate (for example, a processing instruction).
       * @throws SAXException


JBS: https://bugs.openjdk.java.net/browse/JDK-8209873

Thanks,
Joe


From lance.andersen at oracle.com  Thu Aug 23 19:34:24 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 Aug 2018 15:34:24 -0400
Subject: =?utf-8?Q?Re=3A_RFR=28JDK12/JAXP/java=2Exml=29_8209873=3A_Typo_in?=
 =?utf-8?Q?_javax=2Exml=2Evalidation=2EValidator=2Evalidate=E2=80=8B_docum?=
 =?utf-8?Q?entation?=
In-Reply-To: <5B7F0AA1.5050608@oracle.com>
References: <5B7F0AA1.5050608@oracle.com>
Message-ID: <56A877A5-9F28-44B1-8E5B-378289C957C1@oracle.com>

+1
> On Aug 23, 2018, at 3:27 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a quick fix for a typo in javax.xml.validation.Validator:
> 
> diff --git a/src/java.xml/share/classes/javax/xml/validation/Validator.java b/src/java.xml/share/classes/javax/xml/validation/Validator.java
> --- a/src/java.xml/share/classes/javax/xml/validation/Validator.java
> +++ b/src/java.xml/share/classes/javax/xml/validation/Validator.java
> @@ -214,7 +214,7 @@
>      *
>      * @throws IllegalArgumentException
>      *      If the {@code Result} type doesn't match the
> -     *      {@code Source} type of if the {@code Source}
> +     *      {@code Source} type or if the {@code Source}
>      *      is an XML artifact that the implementation cannot
>      *      validate (for example, a processing instruction).
>      * @throws SAXException
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209873
> 
> Thanks,
> Joe
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From ecki at zusammenkunft.net  Thu Aug 23 19:49:39 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 23 Aug 2018 19:49:39 +0000
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>,
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
Message-ID: <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>

Yes, Seeburger AG OCA should be on file (b.eckenfels at seeburger.de)

Thanks for following up

Did you had any opinion on the synthetic accessors as well?
Gru?
Bernd

--
https://Bernd.eckenfels.net

________________________________
Von: Daniel Fuchs <daniel.fuchs at oracle.com>
Gesendet: Donnerstag, August 23, 2018 11:20 AM
An: Bernd Eckenfels; core-libs-dev at openjdk.java.net
Betreff: Re: (XS) java.logging Level.java minor cleanups

Hi Bernd,

Good finding! I agree with the proposed cleanup.
I am always a bit uneasy of touching these classes
as they have a propensity to come back and bite you
from behind when you're not looking ;-)

I have applied your patch and sent it to our test system
for more confidence and everything went well.

I'll happily sponsor your patch.
You did sign the OCA - right?

MfG,

-- daniel

On 11/08/2018 20:31, Bernd Eckenfels wrote:
> Hello,
>
> while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but not in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level) in the master queries a unused class name (pn) and it can use the method reference instead of Lambda. See patch below.
>
> There seems to be also a opportunity to use computeIfAbsent in a unrelated method add(Level), not sure if this is wanted, what do you think?
>
>
> index dbc27124d33..401c6dc73e0 100644
> --- a/src/java.logging/share/classes/java/util/logging/Level.java
> +++ b/src/java.logging/share/classes/java/util/logging/Level.java
> @@ -610,10 +610,7 @@ public class Level implements java.io.Serializable {
> }
>
> private static void registerWithClassLoader(Level customLevel) {
> - PrivilegedAction<ClassLoader> pa =
> - () -> customLevel.getClass().getClassLoader();
> - PrivilegedAction<String> pn = customLevel.getClass()::getName;
> - final String name = AccessController.doPrivileged(pn);
> + PrivilegedAction<ClassLoader> pa = customLevel.getClass()::getClassLoader;
> final ClassLoader cl = AccessController.doPrivileged(pa);
> CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
> .add(customLevel);
> @@ -624,19 +621,10 @@ public class Level implements java.io.Serializable {
> // the mirroredLevel object is always added to the list
> // before the custom Level instance
> KnownLevel o = new KnownLevel(l);
> - List<KnownLevel> list = nameToLevels.get(l.name);
> - if (list == null) {
> - list = new ArrayList<>();
> - nameToLevels.put(l.name, list);
> - }
> - list.add(o);
> -
> - list = intToLevels.get(l.value);
> - if (list == null) {
> - list = new ArrayList<>();
> - intToLevels.put(l.value, list);
> - }
> - list.add(o);
> + nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
> + .add(o);
> + intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
> + .add(o);
>
> // keep the custom level reachable from its class loader
> // This will ensure that custom level values are not GC'ed
>
>
> I am happy if anyone can sponsor this change.
>
> BTW: I get a synthetic Accessor warning on l.name/value, is this what nestmates will resolve ? is it worth adjusting the modifiers for those fields anyway?
>
> Gruss
> Bernd
>


From huizhe.wang at oracle.com  Thu Aug 23 19:54:31 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 23 Aug 2018 12:54:31 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8209873: Typo in =?UTF-8?B?amF2YXgu?=
 =?UTF-8?B?eG1sLnZhbGlkYXRpb24uVmFsaWRhdG9yLnZhbGlkYXRl4oCLIGRvY3VtZW50YXQ=?=
 =?UTF-8?B?aW9u?=
In-Reply-To: <56A877A5-9F28-44B1-8E5B-378289C957C1@oracle.com>
References: <5B7F0AA1.5050608@oracle.com>
 <56A877A5-9F28-44B1-8E5B-378289C957C1@oracle.com>
Message-ID: <5B7F10F7.9080808@oracle.com>

Thanks Lance!

Joe

On 8/23/18, 12:34 PM, Lance Andersen wrote:
> +1
>> On Aug 23, 2018, at 3:27 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review a quick fix for a typo in javax.xml.validation.Validator:
>>
>> diff --git 
>> a/src/java.xml/share/classes/javax/xml/validation/Validator.java 
>> b/src/java.xml/share/classes/javax/xml/validation/Validator.java
>> --- a/src/java.xml/share/classes/javax/xml/validation/Validator.java
>> +++ b/src/java.xml/share/classes/javax/xml/validation/Validator.java
>> @@ -214,7 +214,7 @@
>>      *
>>      * @throws IllegalArgumentException
>>      *      If the {@code Result} type doesn't match the
>> -     *      {@code Source} type of if the {@code Source}
>> +     *      {@code Source} type or if the {@code Source}
>>      *      is an XML artifact that the implementation cannot
>>      *      validate (for example, a processing instruction).
>>      * @throws SAXException
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209873
>>
>> Thanks,
>> Joe
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From mandy.chung at oracle.com  Thu Aug 23 20:02:43 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 23 Aug 2018 15:02:43 -0500
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
 <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>



On 8/23/18 2:49 PM, Bernd Eckenfels wrote:
> 
> Did you had any opinion on the synthetic accessors as well?

:

>> BTW: I get a synthetic Accessor warning on l.name/value, is this
>> what  nestmates will resolve ? is it worth adjusting the modifiers for>> 
those fields anyway?

What warning message did you get?

Mandy

From ecki at zusammenkunft.net  Thu Aug 23 20:41:16 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 23 Aug 2018 22:41:16 +0200
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
 <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>
Message-ID: <5b7f1bec.1c69fb81.58813.9b15@mx.google.com>

Hello Mandy,

the fields Level#name, Level#value and resourceBundleName accessed from KnownLevel inner class are private and therefore an synthetic accessor will be used. Eclipse warns about this.

But, Looking at it again, it is not only a non-issue with JEP 181 in Java 11, it is also hard to fix for 8u since the Level class is public and so the fields really should stay private. (I gues I was just suprised to see any synthetic accessors in Performance critical JCL classes)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: mandy chung
Gesendet: Donnerstag, 23. August 2018 22:02
An: Bernd Eckenfels; Daniel Fuchs
Cc: core-libs-dev at openjdk.java.net
Betreff: Re: (XS) java.logging Level.java minor cleanups



On 8/23/18 2:49 PM, Bernd Eckenfels wrote:
> 
> Did you had any opinion on the synthetic accessors as well?

:

>> BTW: I get a synthetic Accessor warning on l.name/value, is this
>> what  nestmates will resolve ? is it worth adjusting the modifiers for>> 
those fields anyway?

What warning message did you get?

Mandy


From mearvk at outlook.com  Fri Aug 24 01:10:18 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 24 Aug 2018 01:10:18 +0000
Subject: Javac Compiler 
Message-ID: <SN6PR07MB50223FDC5C785E85E95267A9DA360@SN6PR07MB5022.namprd07.prod.outlook.com>

com.sun.tools.javac.main.Main


com.sun.tools.javac.main.Main compiler =
            new com.sun.tools.javac.main.Main("javac");
        return compiler.compile(args).exitCode;

I see this down in jdk.compiler.   The com.sun.tools.javac.main folder doesn't exist.


From mearvk at outlook.com  Fri Aug 24 02:00:13 2018
From: mearvk at outlook.com (mr rupplin)
Date: Fri, 24 Aug 2018 02:00:13 +0000
Subject: Interpreter Function Handler
Message-ID: <SN6PR07MB502278607237572BB658E62FDA360@SN6PR07MB5022.namprd07.prod.outlook.com>

jdk9/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp


Where does Java handle pass by value?  Where can I see that implementation?


Great. Thank you.


From mandy.chung at oracle.com  Fri Aug 24 02:20:40 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 23 Aug 2018 21:20:40 -0500
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <5b7f1bec.1c69fb81.58813.9b15@mx.google.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
 <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>
 <5b7f1bec.1c69fb81.58813.9b15@mx.google.com>
Message-ID: <9c197273-5622-1730-c5a6-d275312f8d22@oracle.com>

Do you find the class files containing the bridge methods.

I checked my JDK build and the Level and KnownLevel classes are in
the same nest as I expect.  Level is the nest host of KnownLevel
which can access Level.name and other fields via getfield.
I also skimmed through the class file and doesn't see the bridge
method.

Are you setting Eclipse with JDK 11 with nestmate support?  I don't
know whether Eclipse has also detected the nestmates though.

Mandy

On 8/23/18 3:41 PM, Bernd Eckenfels wrote:
> Hello Mandy,
> 
> the fields Level#name, Level#value and resourceBundleName accessed from 
> KnownLevel inner class are private and therefore an synthetic accessor 
> will be used. Eclipse warns about this.
> 
> But, Looking at it again, it is not only a non-issue with JEP 181 in 
> Java 11, it is also hard to fix for 8u since the Level class is public 
> and so the fields really should stay private. (I gues I was just 
> suprised to see any synthetic accessors in Performance critical JCL classes)
> 
> Gruss
> 
> Bernd
> 
> -- 
> http://bernd.eckenfels.net
> 
> *Von: *mandy chung <mailto:mandy.chung at oracle.com>
> *Gesendet: *Donnerstag, 23. August 2018 22:02
> *An: *Bernd Eckenfels <mailto:ecki at zusammenkunft.net>; Daniel Fuchs 
> <mailto:daniel.fuchs at oracle.com>
> *Cc: *core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>
> *Betreff: *Re: (XS) java.logging Level.java minor cleanups
> 
> On 8/23/18 2:49 PM, Bernd Eckenfels wrote:
> 
>  >
> 
>  > Did you had any opinion on the synthetic accessors as well?
> 
> :
> 
>  >> BTW: I get a synthetic Accessor warning on l.name/value, is this
> 
>  >> what? nestmates will resolve ? is it worth adjusting the modifiers 
> for>>
> 
> those fields anyway?
> 
> What warning message did you get?
> 
> Mandy
> 

From ioi.lam at oracle.com  Fri Aug 24 03:03:41 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 23 Aug 2018 20:03:41 -0700
Subject: Javac Compiler
In-Reply-To: <SN6PR07MB50223FDC5C785E85E95267A9DA360@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB50223FDC5C785E85E95267A9DA360@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <249133b4-1014-06af-cce9-289bb1853495@oracle.com>



$ find . -name main | grep javac
./src/jdk.compiler/share/classes/com/sun/tools/javac/main
./test/langtools/tools/javac/main




On 8/23/18 6:10 PM, mr rupplin wrote:
> com.sun.tools.javac.main.Main
>
>
> com.sun.tools.javac.main.Main compiler =
>              new com.sun.tools.javac.main.Main("javac");
>          return compiler.compile(args).exitCode;
>
> I see this down in jdk.compiler.   The com.sun.tools.javac.main folder doesn't exist.
>


From daniel.fuchs at oracle.com  Fri Aug 24 08:52:02 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 24 Aug 2018 09:52:02 +0100
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
 <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <d726b856-72e2-44a7-75b8-b2fd280e8ec0@oracle.com>
Message-ID: <f05cbdf0-a532-cd0e-c360-6f59e020726e@oracle.com>

Hi Bernd, Mandy,

Sorry I missed answering your question!

On 23/08/2018 21:02, mandy chung wrote:
> 
> 
> On 8/23/18 2:49 PM, Bernd Eckenfels wrote:
>>
>> Did you had any opinion on the synthetic accessors as well?
> 
> :
> 
>>> BTW: I get a synthetic Accessor warning on l.name/value, is this
>>> what? nestmates will resolve ? is it worth adjusting the modifiers for>> 
> those fields anyway?
> 
> What warning message did you get?

I suspect these warning are emitted only by your IDE right?

AFAIU then the concern therefore is mostly a perf/size issue where
before nestmates [1] the compiler would have to generate synthetic
accessors for accessing Level.name / Level.value from a nested
inner class. It is my understanding that nestmates should
remove the needs for these accessors, and given that nestmates
are coming I would rather leave these fields private, rather
than extending their accessibility to the whole package.

[1] https://bugs.openjdk.java.net/browse/JDK-8046171

best regards,

-- daniel

> 
> Mandy


From christoph.langer at sap.com  Fri Aug 24 09:33:05 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Aug 2018 09:33:05 +0000
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
Message-ID: <092fc7b85e0042a18261723ec7488879@sap.com>

Hi,

please review and give feedback for this augmentation of java.io.Console.

We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console.

Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/

I'll also open a CSR for this, but I'll wait for some feedback on our proposal first.

Thanks & Best regards
Christoph


From claes.redestad at oracle.com  Fri Aug 24 09:38:35 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 24 Aug 2018 11:38:35 +0200
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <1806747601.606848.1535037139169.JavaMail.zimbra@u-pem.fr>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
 <1806747601.606848.1535037139169.JavaMail.zimbra@u-pem.fr>
Message-ID: <4c6f280d-c3ea-ea76-95ea-ef19ce39eb6b@oracle.com>

Hi,

On 2018-08-23 17:12, Remi Forax wrote:
> Hi Claes,
>
>    useCanonPrefixCache = useCanonCaches ? getBooleanProperty("sun.io.useCanonPrefixCache",false) : false;
> can be written
>    useCanonPrefixCache = useCanonCaches && getBooleanProperty("sun.io.useCanonPrefixCache",false);

sure.
> and the name useCanonCaches/useCanonPrefixCache should follow the coding convention USE_CANON_CACHES/USE_CANON_PREFIX_CACHE.

While agreeable, I think there's also value that the constants reflect 
the property names used to set them, while renaming the properties feels 
far out of scope. I'll opt not to rename anything, unless you insist.

/Claes

From forax at univ-mlv.fr  Fri Aug 24 10:05:48 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 24 Aug 2018 12:05:48 +0200 (CEST)
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <4c6f280d-c3ea-ea76-95ea-ef19ce39eb6b@oracle.com>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
 <1806747601.606848.1535037139169.JavaMail.zimbra@u-pem.fr>
 <4c6f280d-c3ea-ea76-95ea-ef19ce39eb6b@oracle.com>
Message-ID: <1978696518.712729.1535105148038.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 24 Ao?t 2018 11:38:35
> Objet: Re: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap

> Hi,
> 
> On 2018-08-23 17:12, Remi Forax wrote:
>> Hi Claes,
>>
>>    useCanonPrefixCache = useCanonCaches ?
>>    getBooleanProperty("sun.io.useCanonPrefixCache",false) : false;
>> can be written
>>    useCanonPrefixCache = useCanonCaches &&
>>    getBooleanProperty("sun.io.useCanonPrefixCache",false);
> 
> sure.
>> and the name useCanonCaches/useCanonPrefixCache should follow the coding
>> convention USE_CANON_CACHES/USE_CANON_PREFIX_CACHE.
> 
> While agreeable, I think there's also value that the constants reflect
> the property names used to set them, while renaming the properties feels
> far out of scope. I'll opt not to rename anything, unless you insist.

i will not insist,
so looks good to me !

> 
> /Claes

R?mi

From forax at univ-mlv.fr  Fri Aug 24 10:09:47 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 24 Aug 2018 12:09:47 +0200 (CEST)
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to
 query console width and height
In-Reply-To: <092fc7b85e0042a18261723ec7488879@sap.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
Message-ID: <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>

Hi Christoph,
getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird.
Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention.

regards,
R?mi

----- Mail original -----
> De: "Christoph Langer" <christoph.langer at sap.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height

> Hi,
> 
> please review and give feedback for this augmentation of java.io.Console.
> 
> We have users that have the need to query for Width and Height of the console
> device in Java. In our own JVM implementation we had given them this hook as a
> custom extension already quite some time ago. We think, however, that it is a
> worthwhile augmentation of java.io.Console.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
> 
> I'll also open a CSR for this, but I'll wait for some feedback on our proposal
> first.
> 
> Thanks & Best regards
> Christoph

From vyom.tewari at oracle.com  Fri Aug 24 10:35:13 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Fri, 24 Aug 2018 16:05:13 +0530
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server
 has sent a disconnection
Message-ID: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>

Hi All,

Please review this simple fix below

webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html

bugid: https://bugs.openjdk.java.net/browse/JDK-8205330

This fix will resolve the race in LdapClient? where we are explicitly 
making "null" to LdapClient.conn.

Thanks,

Vyom


From maurizio.cimadamore at oracle.com  Fri Aug 24 10:36:48 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Aug 2018 11:36:48 +0100
Subject: Javac Compiler
In-Reply-To: <249133b4-1014-06af-cce9-289bb1853495@oracle.com>
References: <SN6PR07MB50223FDC5C785E85E95267A9DA360@SN6PR07MB5022.namprd07.prod.outlook.com>
 <249133b4-1014-06af-cce9-289bb1853495@oracle.com>
Message-ID: <1aa7d2eb-83f0-d00f-d937-8e23cff429dc@oracle.com>

Hi,
if you are looking at the compiler code base and would like some 
specific help, please consider posting at the compiler-dev mailing list:

http://mail.openjdk.java.net/pipermail/compiler-dev/

Cheers
Maurizio


On 24/08/18 04:03, Ioi Lam wrote:
>
>
> $ find . -name main | grep javac
> ./src/jdk.compiler/share/classes/com/sun/tools/javac/main
> ./test/langtools/tools/javac/main
>
>
>
>
> On 8/23/18 6:10 PM, mr rupplin wrote:
>> com.sun.tools.javac.main.Main
>>
>>
>> com.sun.tools.javac.main.Main compiler =
>> ???????????? new com.sun.tools.javac.main.Main("javac");
>> ???????? return compiler.compile(args).exitCode;
>>
>> I see this down in jdk.compiler.?? The com.sun.tools.javac.main 
>> folder doesn't exist.
>>
>


From peter.levart at gmail.com  Fri Aug 24 11:06:06 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 24 Aug 2018 13:06:06 +0200
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
Message-ID: <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>



On 08/24/2018 12:09 PM, Remi Forax wrote:
> Hi Christoph,
> getWidth() and getHeight() should be instance methods and not static methods, providing the weight or the height if there is no console seems weird.
> Also, they should be named width() and height() given the rest of the methods of java.io.Console doesn't use the "get" convention.
>
> regards,
> R?mi

They could also return OptionalInt to force user to think about 
"not-available" situations.

Regards, Peter

>
> ----- Mail original -----
>> De: "Christoph Langer" <christoph.langer at sap.com>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
>> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
>> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
>> Hi,
>>
>> please review and give feedback for this augmentation of java.io.Console.
>>
>> We have users that have the need to query for Width and Height of the console
>> device in Java. In our own JVM implementation we had given them this hook as a
>> custom extension already quite some time ago. We think, however, that it is a
>> worthwhile augmentation of java.io.Console.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
>>
>> I'll also open a CSR for this, but I'll wait for some feedback on our proposal
>> first.
>>
>> Thanks & Best regards
>> Christoph


From james.laskey at oracle.com  Fri Aug 24 12:57:08 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 24 Aug 2018 09:57:08 -0300
Subject: RFR - CSR JDK-8200435 - String::align, String::indent (after
 revisions)
Message-ID: <FA276D2E-961A-4D62-8DD8-50F97F289CF0@oracle.com>

After further discussion, the API specs for these methods have been extensively reworked and the CSR moved back to Proposal stage.

Please review https://bugs.openjdk.java.net/browse/JDK-8200435

Cheers,

? Jim

From christoph.langer at sap.com  Fri Aug 24 13:18:23 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Aug 2018 13:18:23 +0000
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
Message-ID: <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>

Hi R?mi, Hi Peter,

thanks for your quick answers.

What you've suggested, R?mi, is perfectly right. I've updated my webrev. The methods were copied from our old implementation (of a different class) where they were provided as static.

I will also think of using an optional. I'm furthermore wondering if we should provide a method "dimensions()" returning an (optional) java.io.Console.Dimension object that contains both height and width...

Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/ 

Best regards
Christoph

> -----Original Message-----
> From: Peter Levart <peter.levart at gmail.com>
> Sent: Freitag, 24. August 2018 13:06
> To: Remi Forax <forax at univ-mlv.fr>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Baesken, Matthias
> <matthias.baesken at sap.com>
> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide methods to
> query console width and height
> 
> 
> 
> On 08/24/2018 12:09 PM, Remi Forax wrote:
> > Hi Christoph,
> > getWidth() and getHeight() should be instance methods and not static
> methods, providing the weight or the height if there is no console seems
> weird.
> > Also, they should be named width() and height() given the rest of the
> methods of java.io.Console doesn't use the "get" convention.
> >
> > regards,
> > R?mi
> 
> They could also return OptionalInt to force user to think about
> "not-available" situations.
> 
> Regards, Peter
> 
> >
> > ----- Mail original -----
> >> De: "Christoph Langer" <christoph.langer at sap.com>
> >> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> >> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
> >> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
> >> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query
> console width and height
> >> Hi,
> >>
> >> please review and give feedback for this augmentation of java.io.Console.
> >>
> >> We have users that have the need to query for Width and Height of the
> console
> >> device in Java. In our own JVM implementation we had given them this
> hook as a
> >> custom extension already quite some time ago. We think, however, that
> it is a
> >> worthwhile augmentation of java.io.Console.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
> >>
> >> I'll also open a CSR for this, but I'll wait for some feedback on our proposal
> >> first.
> >>
> >> Thanks & Best regards
> >> Christoph


From peter.levart at gmail.com  Fri Aug 24 13:41:28 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 24 Aug 2018 15:41:28 +0200
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
 <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
Message-ID: <582bff0e-6319-d289-5c5f-1c4153d8cb58@gmail.com>



On 08/24/2018 03:18 PM, Langer, Christoph wrote:
> Hi R?mi, Hi Peter,
>
> thanks for your quick answers.
>
> What you've suggested, R?mi, is perfectly right. I've updated my webrev. The methods were copied from our old implementation (of a different class) where they were provided as static.
>
> I will also think of using an optional. I'm furthermore wondering if we should provide a method "dimensions()" returning an (optional) java.io.Console.Dimension object that contains both height and width...

Yes, a good idea. In AWT/Swing such methods are called getSize() or size():

 ??? /**
 ???? * @deprecated As of JDK version 1.1,
 ???? * replaced by <code>getSize()</code>.
 ???? */
 ??? @Deprecated
 ??? public Dimension size() {
 ??????? return new Dimension(width, height);
 ??? }

It seems that at some stage, methods like size() have been @Deprecated 
and replaced with getSize(). Now we're going back from getSize() to 
size() as the preferred name...

I suggest you create a private native method that returns both 
dimensions (encoded in a jlong for example, with non-existence being 
-1L) and then do the conversion (to Optional<Console.Dimension>) in a 
public Java method. It would be much simpler than creating objects in 
native code...

Regards, Peter

>
> Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Peter Levart <peter.levart at gmail.com>
>> Sent: Freitag, 24. August 2018 13:06
>> To: Remi Forax <forax at univ-mlv.fr>; Langer, Christoph
>> <christoph.langer at sap.com>
>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Baesken, Matthias
>> <matthias.baesken at sap.com>
>> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide methods to
>> query console width and height
>>
>>
>>
>> On 08/24/2018 12:09 PM, Remi Forax wrote:
>>> Hi Christoph,
>>> getWidth() and getHeight() should be instance methods and not static
>> methods, providing the weight or the height if there is no console seems
>> weird.
>>> Also, they should be named width() and height() given the rest of the
>> methods of java.io.Console doesn't use the "get" convention.
>>> regards,
>>> R?mi
>> They could also return OptionalInt to force user to think about
>> "not-available" situations.
>>
>> Regards, Peter
>>
>>> ----- Mail original -----
>>>> De: "Christoph Langer" <christoph.langer at sap.com>
>>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
>>>> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
>>>> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to query
>> console width and height
>>>> Hi,
>>>>
>>>> please review and give feedback for this augmentation of java.io.Console.
>>>>
>>>> We have users that have the need to query for Width and Height of the
>> console
>>>> device in Java. In our own JVM implementation we had given them this
>> hook as a
>>>> custom extension already quite some time ago. We think, however, that
>> it is a
>>>> worthwhile augmentation of java.io.Console.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
>>>>
>>>> I'll also open a CSR for this, but I'll wait for some feedback on our proposal
>>>> first.
>>>>
>>>> Thanks & Best regards
>>>> Christoph


From matthias.baesken at sap.com  Fri Aug 24 14:52:59 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 24 Aug 2018 14:52:59 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
Message-ID: <69b2a09539384016b890e64e71700809@sap.com>

Hello, I created another webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/

- use now  jarPath  instead of  jarpath  in the java security file
-  moved the parsing of the property  to a more general location (separate class jdk/internal/util/SecuritySystemPropertyHelper.java  )
-  read now  from the InputStream and check for error conditions *before*  setting jarFilename    in the Manifest  constructor        


Best regards , Matthias


> -----Original Message-----
> From: Sean Mullan <sean.mullan at oracle.com>
> Sent: Freitag, 10. August 2018 17:39
> To: Baesken, Matthias <matthias.baesken at sap.com>; Chris Hegarty
> <chris.hegarty at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
> dev at openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> I need more time to finish my review but here are some initial comments:
> 
> - java.security
> 
> 1079 #  jarpath - enables more detailed information in the IOExceptions
> thrown
> 
> Use "jarPath" to be consistent with "hostInfo".
> 
> 1080 #            by java.util.jar.Attributes  and java.util.jar.Manifest
> 
> and java.util.jar.JarFile
> 
> - Manifest.java
> 
> 57     private String jarFilename = null;
> 
> Not necessary to set it to null, as that is the default.
> 
>    82     Manifest(InputStream is, String jarFilename) throws IOException {
>    83         this.jarFilename = jarFilename;
>    84         read(is);
>    85     }
> 
> Read from the InputStream and check for error conditions *before*
> setting jarFilename (switch lines 83 & 84). This is a general best
> practice but can also protect against finalizer attacks. See JSCG 7-3
> for more info:
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7
> 
> - Attributes.java
> 
> As Chris and Alan mentioned, you should move the parsing of the property
> to a more general location so it can be used by other code that uses
> this property.
> 
> --Sean
> 
> On 8/8/18 11:00 AM, Sean Mullan wrote:
> > Cross-posting to security-dev since this fix is security related and
> > should also be reviewed there.
> >
> > --Sean
> >
> > On 8/7/18 11:00 AM, Baesken, Matthias wrote:
> >> Ping ....? ??? , any reviews / comments ?
> >>
> >> Thanks , Matthias
> >>
> >>> -----Original Message-----
> >>> From: Baesken, Matthias
> >>> Sent: Dienstag, 31. Juli 2018 12:28
> >>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>; Alan Bateman
> >>> <Alan.Bateman at oracle.com>
> >>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> >>> <goetz.lindenmaier at sap.com>; Langer, Christoph
> >>> <christoph.langer at sap.com>
> >>> Subject: RE: [RFR] 8205525 : Improve exception messages during
> manifest
> >>> parsing of jar archives
> >>>
> >>> Hello ,
> >>> looks like? the? generalization of? the `includeInExceptions`
> >>> security?? property
> >>> is now in jdk/jdk? after
> >>>
> >>> "8207846: Generalize the jdk.net.includeInExceptions security property"
> >>>
> >>> was added, great news? and thanks to Chris for driving this !
> >>>
> >>> I use this security property now as well , and updated the? change :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.3/
> >>>
> >>> I updated the CSR as well :
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>>
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Chris Hegarty <chris.hegarty at oracle.com>
> >>>> Sent: Donnerstag, 19. Juli 2018 14:54
> >>>> To: Alan Bateman <Alan.Bateman at oracle.com>; Baesken, Matthias
> >>>> <matthias.baesken at sap.com>
> >>>> Cc: core-libs-dev at openjdk.java.net; Lindenmaier, Goetz
> >>>> <goetz.lindenmaier at sap.com>
> >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during
> manifest
> >>>> parsing of jar archives
> >>>>
> >>>>
> >>>>> On 19 Jul 2018, at 11:46, Alan Bateman <Alan.Bateman at oracle.com>
> >>>> wrote:
> >>>>>
> >>>>> On 19/07/2018 09:07, Baesken, Matthias wrote:
> >>>>>> Hello, in the meantime I? prepared a CSR :
> >>>>>>
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207768
> >>>>>>
> >>>>>>
> >>>>>>> jdk.includeInExceptions expands the scope. That might be okay but
> we
> >>>>>>> will need to re-visit jdk.net.includeInExceptions and also move the
> >>>>>>> support to somewhere in jdk.internal so that it can be used by
> other
> >>>>>>> code in java.base.
> >>>>>> Is there some support code for? " jdk.net.includeInExceptions "
> >>>>>> or do
> >>>> you just? mean? the name of the property ?
> >>>>>>
> >>>>> Chris is right that it's a bit premature to submit a CSR while the
> >>>>> question
> >>> on
> >>>> whether to rename the existing security property is on the table. I
> >>>> have no
> >>>> objection to doing that.
> >>>>
> >>>> I filed the following issue to generalize the `includeInExceptions`
> >>>> security
> >>>> ? property:
> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8207846
> >>>>
> >>>> I would like to resolve 8207846 first, then 8205525 can propose to
> >>>> add the
> >>>> new argument value, `jarPath`.
> >>>>
> >>>> -Chris.

From chris.hegarty at oracle.com  Fri Aug 24 15:22:44 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 24 Aug 2018 16:22:44 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
Message-ID: <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>

Hi Vyom,

On 24/08/18 11:35, vyom tewari wrote:
> Hi All,
> 
> Please review this simple fix below
> 
> webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html
> 
> bugid: https://bugs.openjdk.java.net/browse/JDK-8205330
> 
> This fix will resolve the race in LdapClient? where we are explicitly 
> making "null" to LdapClient.conn.

Sorry, I don't know this code all that well, but I think
that more explanation will be needed before this code
can be reviewed.

The LdapClient and the Connection seem to be loosely
coupled. I think part of this is to allow the LdapClient
to be GC'ed and finalized separately to the Connection
( that can be reused ). Not setting `conn` to null could
have a negative impact on this loose coupling. I also
note that the synchronization is implemented poorly in
the LdapClient, `conn` is operated on both from within
synchronized blocks and from unsynchronized blocks (
which I think is the reason you see the unexpected
null ).

-Chris.

From xueming.shen at oracle.com  Fri Aug 24 16:58:59 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 24 Aug 2018 09:58:59 -0700
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <5B8038CD.3040305@oracle.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
 <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
 <582bff0e-6319-d289-5c5f-1c4153d8cb58@gmail.com>
 <5B8038CD.3040305@oracle.com>
Message-ID: <5B803953.5060404@oracle.com>

To the core-libs ...

On 8/24/18, 9:56 AM, Xueming Shen wrote:
> Hi Langer,
>
> I would suggest to add explicit wording to emphasize the "size" means 
> the rows
> and columns in characters, not the pixels.
>
> It appears attractive to have a Console.Dimension to abstract the size 
> and make it
> an "atomic" access but I'm not sure if it's really worth the cost to 
> have an extra
> class merely for this purpose. getWidth/Height might be just good 
> enough for most
> possible use scenario for Console class. Maybe we can add a getSize() 
> when we
> have a better abstract/choice later, for example, "tuples/pair" ? :-)
>
> A little background, the design decision of the Console class back 
> then was to avoid
> those platform dependent term curses related stuff, so those size, 
> cursor related
> functionality were purposely removed from the final API and 
> implementation ...
>
> Thanks,
> Sherman
>
> On 8/24/18, 6:41 AM, Peter Levart wrote:
>>
>>
>> On 08/24/2018 03:18 PM, Langer, Christoph wrote:
>>> Hi R?mi, Hi Peter,
>>>
>>> thanks for your quick answers.
>>>
>>> What you've suggested, R?mi, is perfectly right. I've updated my 
>>> webrev. The methods were copied from our old implementation (of a 
>>> different class) where they were provided as static.
>>>
>>> I will also think of using an optional. I'm furthermore wondering if 
>>> we should provide a method "dimensions()" returning an (optional) 
>>> java.io.Console.Dimension object that contains both height and width...
>>
>> Yes, a good idea. In AWT/Swing such methods are called getSize() or 
>> size():
>>
>>     /**
>>      * @deprecated As of JDK version 1.1,
>>      * replaced by <code>getSize()</code>.
>>      */
>>     @Deprecated
>>     public Dimension size() {
>>         return new Dimension(width, height);
>>     }
>>
>> It seems that at some stage, methods like size() have been 
>> @Deprecated and replaced with getSize(). Now we're going back from 
>> getSize() to size() as the preferred name...
>>
>> I suggest you create a private native method that returns both 
>> dimensions (encoded in a jlong for example, with non-existence being 
>> -1L) and then do the conversion (to Optional<Console.Dimension>) in a 
>> public Java method. It would be much simpler than creating objects in 
>> native code...
>>
>> Regards, Peter
>>
>>>
>>> Here is a new webrev: 
>>> http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
>>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Peter Levart <peter.levart at gmail.com>
>>>> Sent: Freitag, 24. August 2018 13:06
>>>> To: Remi Forax <forax at univ-mlv.fr>; Langer, Christoph
>>>> <christoph.langer at sap.com>
>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Baesken, Matthias
>>>> <matthias.baesken at sap.com>
>>>> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide 
>>>> methods to
>>>> query console width and height
>>>>
>>>>
>>>>
>>>> On 08/24/2018 12:09 PM, Remi Forax wrote:
>>>>> Hi Christoph,
>>>>> getWidth() and getHeight() should be instance methods and not static
>>>> methods, providing the weight or the height if there is no console 
>>>> seems
>>>> weird.
>>>>> Also, they should be named width() and height() given the rest of the
>>>> methods of java.io.Console doesn't use the "get" convention.
>>>>> regards,
>>>>> R?mi
>>>> They could also return OptionalInt to force user to think about
>>>> "not-available" situations.
>>>>
>>>> Regards, Peter
>>>>
>>>>> ----- Mail original -----
>>>>>> De: "Christoph Langer" <christoph.langer at sap.com>
>>>>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>>>> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
>>>>>> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
>>>>>> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to 
>>>>>> query
>>>> console width and height
>>>>>> Hi,
>>>>>>
>>>>>> please review and give feedback for this augmentation of 
>>>>>> java.io.Console.
>>>>>>
>>>>>> We have users that have the need to query for Width and Height of 
>>>>>> the
>>>> console
>>>>>> device in Java. In our own JVM implementation we had given them this
>>>> hook as a
>>>>>> custom extension already quite some time ago. We think, however, 
>>>>>> that
>>>> it is a
>>>>>> worthwhile augmentation of java.io.Console.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
>>>>>>
>>>>>> I'll also open a CSR for this, but I'll wait for some feedback on 
>>>>>> our proposal
>>>>>> first.
>>>>>>
>>>>>> Thanks & Best regards
>>>>>> Christoph
>>
>


From seth.lytle at gmail.com  Fri Aug 24 17:21:06 2018
From: seth.lytle at gmail.com (seth lytle)
Date: Fri, 24 Aug 2018 13:21:06 -0400
Subject: JEP 330 class loader getResourceAsStream
Message-ID: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>

JEP 330 (launch single-file source programs) uses a MemoryClassLoader. the
compiled bytecode is stored in byte arrays in memory and is never written
to file. currently, the bytecode is not exposed as resources and it would
be advantageous to do so (enabling the use of eg ASM to modify the classes
to implement continuations). this class loader has no resources other than
the bytecode

getResourceAsStream would be easy to implement. getResource would be
significantly harder - a new url scheme and associated plumbing would be
needed

jonathon gibbons wrote on compiler-dev:
> I would defer to ClassLoader experts as to whether it is reasonable
> to provide getResourceAsStream but not getResource.
>
> It might be reasonable the jdk.compiler module to provide a
URLStreamHandlerProvider for these URLs;
> that would require some consideration.



is it reasonable to expose a resource via getResourceAsStream that's not
available via getResource ?


the javadocs for getResource state "returns ... null if ... a URL could not
be constructed to locate the resource". the javadocs for
getResourceAsStream do not include such verbage, which appears to be
precedent for such an arrangement

From roger.riggs at oracle.com  Fri Aug 24 17:25:03 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 24 Aug 2018 13:25:03 -0400
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <5B803953.5060404@oracle.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
 <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
 <582bff0e-6319-d289-5c5f-1c4153d8cb58@gmail.com>
 <5B8038CD.3040305@oracle.com> <5B803953.5060404@oracle.com>
Message-ID: <ee85d5d8-b716-087a-ffab-ca48e3e638d7@oracle.com>

Hi,

This feels like a pretty slippery slope; not enough for real terminal 
emulation;
what kind of terminal is it?, etc.? Not enough for jshell/nashorn, which 
imported a whole
package to support command line editing. ? (jline - module 
jdk.internal.le/ed)

Regardless, keep it simple! There are very few terminals in the cloud.

On 8/24/18 12:58 PM, Xueming Shen wrote:
> To the core-libs ...
>
> On 8/24/18, 9:56 AM, Xueming Shen wrote:
>> Hi Langer,
>>
>> I would suggest to add explicit wording to emphasize the "size" means 
>> the rows
>> and columns in characters, not the pixels.
>>
>> It appears attractive to have a Console.Dimension to abstract the 
>> size and make it
>> an "atomic" access but I'm not sure if it's really worth the cost to 
>> have an extra
>> class merely for this purpose. getWidth/Height might be just good 
>> enough for most
>> possible use scenario for Console class. Maybe we can add a getSize() 
>> when we
>> have a better abstract/choice later, for example, "tuples/pair" ? :-)
+1
>>
>> A little background, the design decision of the Console class back 
>> then was to avoid
>> those platform dependent term curses related stuff, so those size, 
>> cursor related
>> functionality were purposely removed from the final API and 
>> implementation ...
>>
>> Thanks,
>> Sherman
>>
>> On 8/24/18, 6:41 AM, Peter Levart wrote:
>>>
>>>
>>> On 08/24/2018 03:18 PM, Langer, Christoph wrote:
>>>> Hi R?mi, Hi Peter,
>>>>
>>>> thanks for your quick answers.
>>>>
>>>> What you've suggested, R?mi, is perfectly right. I've updated my 
>>>> webrev. The methods were copied from our old implementation (of a 
>>>> different class) where they were provided as static.
>>>>
>>>> I will also think of using an optional. I'm furthermore wondering 
>>>> if we should provide a method "dimensions()" returning an 
>>>> (optional) java.io.Console.Dimension object that contains both 
>>>> height and width...
>>>
>>> Yes, a good idea. In AWT/Swing such methods are called getSize() or 
>>> size():
>>>
>>> ??? /**
>>> ???? * @deprecated As of JDK version 1.1,
>>> ???? * replaced by <code>getSize()</code>.
>>> ???? */
>>> ??? @Deprecated
>>> ??? public Dimension size() {
>>> ??????? return new Dimension(width, height);
>>> ??? }
>>>
>>> It seems that at some stage, methods like size() have been 
>>> @Deprecated and replaced with getSize(). Now we're going back from 
>>> getSize() to size() as the preferred name...
>>>
>>> I suggest you create a private native method that returns both 
>>> dimensions (encoded in a jlong for example, with non-existence being 
>>> -1L) and then do the conversion (to Optional<Console.Dimension>) in 
>>> a public Java method. It would be much simpler than creating objects 
>>> in native code...
>>>
>>> Regards, Peter
>>>
>>>>
>>>> Here is a new webrev: 
>>>> http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
>>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Levart <peter.levart at gmail.com>
>>>>> Sent: Freitag, 24. August 2018 13:06
>>>>> To: Remi Forax <forax at univ-mlv.fr>; Langer, Christoph
>>>>> <christoph.langer at sap.com>
>>>>> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Baesken, Matthias
>>>>> <matthias.baesken at sap.com>
>>>>> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide 
>>>>> methods to
>>>>> query console width and height
>>>>>
>>>>>
>>>>>
>>>>> On 08/24/2018 12:09 PM, Remi Forax wrote:
>>>>>> Hi Christoph,
>>>>>> getWidth() and getHeight() should be instance methods and not static
>>>>> methods, providing the weight or the height if there is no console 
>>>>> seems
>>>>> weird.
>>>>>> Also, they should be named width() and height() given the rest of 
>>>>>> the
>>>>> methods of java.io.Console doesn't use the "get" convention.
>>>>>> regards,
>>>>>> R?mi
>>>>> They could also return OptionalInt to force user to think about
>>>>> "not-available" situations.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>> ----- Mail original -----
>>>>>>> De: "Christoph Langer" <christoph.langer at sap.com>
>>>>>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>>>>> Cc: "Baesken, Matthias" <matthias.baesken at sap.com>
>>>>>>> Envoy?: Vendredi 24 Ao?t 2018 11:33:05
>>>>>>> Objet: RFR: 8209937: Enhance java.io.Console - provide methods 
>>>>>>> to query
>>>>> console width and height
>>>>>>> Hi,
>>>>>>>
>>>>>>> please review and give feedback for this augmentation of 
>>>>>>> java.io.Console.
>>>>>>>
>>>>>>> We have users that have the need to query for Width and Height 
>>>>>>> of the
>>>>> console
>>>>>>> device in Java. In our own JVM implementation we had given them 
>>>>>>> this
>>>>> hook as a
>>>>>>> custom extension already quite some time ago. We think, however, 
>>>>>>> that
>>>>> it is a
>>>>>>> worthwhile augmentation of java.io.Console.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937
>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/
>>>>>>>
>>>>>>> I'll also open a CSR for this, but I'll wait for some feedback 
>>>>>>> on our proposal
>>>>>>> first.
>>>>>>>
>>>>>>> Thanks & Best regards
>>>>>>> Christoph
>>>
>>
>


From david.lloyd at redhat.com  Fri Aug 24 17:27:38 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 24 Aug 2018 12:27:38 -0500
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
Message-ID: <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>

Why not go ahead and implement getResource as well?  It's not *that*
big of a deal to add a URL handler, and it would be a fairly trivial
one.
On Fri, Aug 24, 2018 at 12:21 PM seth lytle <seth.lytle at gmail.com> wrote:
>
> JEP 330 (launch single-file source programs) uses a MemoryClassLoader. the
> compiled bytecode is stored in byte arrays in memory and is never written
> to file. currently, the bytecode is not exposed as resources and it would
> be advantageous to do so (enabling the use of eg ASM to modify the classes
> to implement continuations). this class loader has no resources other than
> the bytecode
>
> getResourceAsStream would be easy to implement. getResource would be
> significantly harder - a new url scheme and associated plumbing would be
> needed
>
> jonathon gibbons wrote on compiler-dev:
> > I would defer to ClassLoader experts as to whether it is reasonable
> > to provide getResourceAsStream but not getResource.
> >
> > It might be reasonable the jdk.compiler module to provide a
> URLStreamHandlerProvider for these URLs;
> > that would require some consideration.
>
>
>
> is it reasonable to expose a resource via getResourceAsStream that's not
> available via getResource ?
>
>
> the javadocs for getResource state "returns ... null if ... a URL could not
> be constructed to locate the resource". the javadocs for
> getResourceAsStream do not include such verbage, which appears to be
> precedent for such an arrangement



-- 
- DML

From brian.burkhalter at oracle.com  Fri Aug 24 18:01:16 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 Aug 2018 11:01:16 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
Message-ID: <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>

This one could still use a Reviewer approval or rejection.

Thanks,

Brian

On Aug 14, 2018, at 1:34 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Bernard,
> 
> On Aug 14, 2018, at 4:13 AM, B. Blaser <bsrbnd at gmail.com> wrote:
> 
>> Seems quite good to me, last notes:
>> 
>> 1) dealing with 'stat/stat64' in 'UnixFileSystem_md.c' might be
>> outside the scope of this fix (?) even if fully pertinent per [1].
> 
> It might be slightly out of scope but I think it?s OK as stat64 was defined inside an
> #if defined(_ALLBSD_SOURCE) conditional compilation block.
> 
>> In the same file, I think '#define dirent dirent64' is probably missing
>> for AIX.
> 
> Fixed.
> 
>> 2) I guess '#if defined(_AIX) ...' is now missing in 'OperatingSystemImpl.c':
>> #if defined(_AIX)
>>  #define DIR DIR64
>>  #define dirent dirent64
>>  #define opendir opendir64
>>  #define readdir readdir64
>>  #define closedir closedir64
>> #endif
> 
> Fixed.
> 
> Webrev updated in place: http://cr.openjdk.java.net/~bpb/8207744/webrev.04/.
> 
> Checks out on Linux-x64, macOS, Solaris-sparcv9, Windows-x64.
> 
>> You'll probably need some more reviews especially for other systems
>> than Linux 64-bit.
> 
> It would not hurt. In any case I do not yet have a Reviewer approval.
> 
> Thanks,
> 
> Brian


From brent.christian at oracle.com  Fri Aug 24 19:14:43 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 24 Aug 2018 12:14:43 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
Message-ID: <ee2a1e4b-3c72-4971-f327-d9c8838a3cbd@oracle.com>

Hi, Brian

The change looks fine to me.
 From my search, I believe all usages have been covered.

-Brent

On 8/24/18 11:01 AM, Brian Burkhalter wrote:
> This one could still use a Reviewer approval or rejection.
> 
> Thanks,
> 
> Brian
> 
> On Aug 14, 2018, at 1:34 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> Hi Bernard,
>>
>> On Aug 14, 2018, at 4:13 AM, B. Blaser <bsrbnd at gmail.com> wrote:
>>
>>> Seems quite good to me, last notes:
>>>
>>> 1) dealing with 'stat/stat64' in 'UnixFileSystem_md.c' might be
>>> outside the scope of this fix (?) even if fully pertinent per [1].
>>
>> It might be slightly out of scope but I think it?s OK as stat64 was defined inside an
>> #if defined(_ALLBSD_SOURCE) conditional compilation block.
>>
>>> In the same file, I think '#define dirent dirent64' is probably missing
>>> for AIX.
>>
>> Fixed.
>>
>>> 2) I guess '#if defined(_AIX) ...' is now missing in 'OperatingSystemImpl.c':
>>> #if defined(_AIX)
>>>   #define DIR DIR64
>>>   #define dirent dirent64
>>>   #define opendir opendir64
>>>   #define readdir readdir64
>>>   #define closedir closedir64
>>> #endif
>>
>> Fixed.
>>
>> Webrev updated in place: http://cr.openjdk.java.net/~bpb/8207744/webrev.04/.
>>
>> Checks out on Linux-x64, macOS, Solaris-sparcv9, Windows-x64.
>>
>>> You'll probably need some more reviews especially for other systems
>>> than Linux 64-bit.
>>
>> It would not hurt. In any case I do not yet have a Reviewer approval.
>>
>> Thanks,
>>
>> Brian
> 

From brian.burkhalter at oracle.com  Fri Aug 24 22:09:45 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 Aug 2018 15:09:45 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <ee2a1e4b-3c72-4971-f327-d9c8838a3cbd@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
 <ee2a1e4b-3c72-4971-f327-d9c8838a3cbd@oracle.com>
Message-ID: <7BBBF58F-2429-48E0-9D01-7FB5AEC4A8BF@oracle.com>

Thanks, Brent!

Brian

On Aug 24, 2018, at 12:14 PM, Brent Christian <brent.christian at oracle.com> wrote:

> The change looks fine to me.
> From my search, I believe all usages have been covered.


From mjpt777 at gmail.com  Sat Aug 25 16:42:23 2018
From: mjpt777 at gmail.com (Martin Thompson)
Date: Sat, 25 Aug 2018 17:42:23 +0100
Subject: DatagramChannel performance issue
Message-ID: <CAChYfd9EngjDJ2SC7bZNZC3=24dxbgL-P-PAiXGGzEA6dwnsVA@mail.gmail.com>

We've been diagnosing a performance issue and isolated it to receiving
on a datagram socket
where we are seeing a significant step down in performance, and
increase in allocation, when
more than one source is sending.

https://github.com/frohoff/jdk8u-jdk/blob/master/src/windows/native/sun/nio/ch/DatagramChannelImpl.c#L138

When receiving from two or more sources we get InetAddress and
InetSocketAddress objects
allocated and they are set via multiple up calls from the JNI code into Java.

A much more efficient implementation would be one that passes down two
ByteBuffers.
One to be filled in for the payload and one for the header. Allocation
on a per packet receive
is not a useful design for a network API.

A read operation is not a valid alternative as we need the sender address.

Regards,
Martin...

From mearvk at outlook.com  Sat Aug 25 18:39:02 2018
From: mearvk at outlook.com (mr rupplin)
Date: Sat, 25 Aug 2018 18:39:02 +0000
Subject: JVM Interpreter 
Message-ID: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>

I am presuming the JVM interpreter is defined/implemented in the the hotspot module since this is a JVM implementation.


I cannot seem to find *any* instruction in it that gets called by a simple "./java -ea Class" call.  We are stumped.


For instance there are methods for local set and reference:


void BytecodeInterpreter::set_stack_slot(intptr_t *tos, address value, int offset) {

    *((address *)&tos[Interpreter::expr_index_at(-offset)]) = value;
}

void BytecodeInterpreter::set_stack_object(intptr_t *tos, oop value, int offset) {

  *((oop *)&tos[Interpreter::expr_index_at(-offset)]) = value;
}

These (and similar in same file) are not being called at all during the JVM interpreter phase (simple java program as reference).  My program creates an object and calls a test method with a single object as reference.

What could be the hang up?  No printf statement seems to work.

Thanks.

Max Rupplin

Software Engineer



From kim.barrett at oracle.com  Sun Aug 26 03:47:41 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 25 Aug 2018 23:47:41 -0400
Subject: JVM Interpreter
In-Reply-To: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <1534949E-159A-4FC1-84CD-81E75ECE6BF3@oracle.com>

> On Aug 25, 2018, at 2:39 PM, mr rupplin <mearvk at outlook.com> wrote:
> 
> I am presuming the JVM interpreter is defined/implemented in the the hotspot module since this is a JVM implementation.

This is probably more of a hotspot-dev or hotspot-runtime-dev kind of question, rather than core-libs.

> I cannot seem to find *any* instruction in it that gets called by a simple "./java -ea Class" call.  We are stumped.
> 
> 
> For instance there are methods for local set and reference:
> 
> 
> void BytecodeInterpreter::set_stack_slot(intptr_t *tos, address value, int offset) {
> 
>    *((address *)&tos[Interpreter::expr_index_at(-offset)]) = value;
> }
> 
> void BytecodeInterpreter::set_stack_object(intptr_t *tos, oop value, int offset) {
> 
>  *((oop *)&tos[Interpreter::expr_index_at(-offset)]) = value;
> }
> 
> These (and similar in same file) are not being called at all during the JVM interpreter phase (simple java program as reference).  My program creates an object and calls a test method with a single object as reference.
> 
> What could be the hang up?  No printf statement seems to work.

I think BytecodeInterpreter is part of CppInterpreter, which I think
is only used by Zero platforms, with the TemplateInterpreter used by
all other platforms.  So unless you are running on a platform that
uses Zero, or specifically built for Zero, I think BytecodeInterpreter
won't be used (and might not even be compiled in?).

> Thanks.
> 
> Max Rupplin
> 
> Software Engineer



From aph at redhat.com  Sun Aug 26 22:07:26 2018
From: aph at redhat.com (Andrew Haley)
Date: Sun, 26 Aug 2018 23:07:26 +0100
Subject: JVM Interpreter
In-Reply-To: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>
References: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>
Message-ID: <08d043cf-a691-e56e-0c04-3616fe7fb128@redhat.com>

On 08/25/2018 07:39 PM, mr rupplin wrote:

> I am presuming the JVM interpreter is defined/implemented in the the
> hotspot module since this is a JVM implementation.

That's right.

> I cannot seem to find *any* instruction in it that gets called by a
> simple "./java -ea Class" call.  We are stumped.

On the "teach a man to fish" priniple, here goes. On most systems the
interpreter is written in assembly language and generated at runtime.

Put a GDB breakpoint here in javaCalls.cpp::

      StubRoutines::call_stub()(
        (address)&link,
        // (intptr_t*)&(result->_value), // see NOTE above (compiler problem)
        result_val_address,          // see NOTE above (compiler problem)
        result_type,
        method(),
        entry_point,
        args->parameters(),
        args->size_of_parameters(),
        CHECK
      );

Step in from the call stub.  You'll need to use "si" rather than
"step", because this is not C++, it's pure hand-crafted assembly
language: the real thing.  You'll see the registers saved, the
parameters copied into the interpreter stack, and the interpreter
entered.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mearvk at outlook.com  Sun Aug 26 22:50:54 2018
From: mearvk at outlook.com (mr rupplin)
Date: Sun, 26 Aug 2018 22:50:54 +0000
Subject: JVM Interpreter
In-Reply-To: <1534949E-159A-4FC1-84CD-81E75ECE6BF3@oracle.com>
References: <SN6PR07MB5022DC09E37717E1CCE1D4C3DA350@SN6PR07MB5022.namprd07.prod.outlook.com>,
 <1534949E-159A-4FC1-84CD-81E75ECE6BF3@oracle.com>
Message-ID: <SN6PR07MB50228BD8C939D96232EDA9E2DA340@SN6PR07MB5022.namprd07.prod.outlook.com>

Thanks you guys.  I will try not to run junk into channel and you guys promise to stay well run.  Ok.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Kim Barrett <kim.barrett at oracle.com>
Sent: Saturday, August 25, 2018 11:47:41 PM
To: mr rupplin
Cc: core-libs-dev at openjdk.java.net
Subject: Re: JVM Interpreter

> On Aug 25, 2018, at 2:39 PM, mr rupplin <mearvk at outlook.com> wrote:
>
> I am presuming the JVM interpreter is defined/implemented in the the hotspot module since this is a JVM implementation.

This is probably more of a hotspot-dev or hotspot-runtime-dev kind of question, rather than core-libs.

> I cannot seem to find *any* instruction in it that gets called by a simple "./java -ea Class" call.  We are stumped.
>
>
> For instance there are methods for local set and reference:
>
>
> void BytecodeInterpreter::set_stack_slot(intptr_t *tos, address value, int offset) {
>
>    *((address *)&tos[Interpreter::expr_index_at(-offset)]) = value;
> }
>
> void BytecodeInterpreter::set_stack_object(intptr_t *tos, oop value, int offset) {
>
>  *((oop *)&tos[Interpreter::expr_index_at(-offset)]) = value;
> }
>
> These (and similar in same file) are not being called at all during the JVM interpreter phase (simple java program as reference).  My program creates an object and calls a test method with a single object as reference.
>
> What could be the hang up?  No printf statement seems to work.

I think BytecodeInterpreter is part of CppInterpreter, which I think
is only used by Zero platforms, with the TemplateInterpreter used by
all other platforms.  So unless you are running on a platform that
uses Zero, or specifically built for Zero, I think BytecodeInterpreter
won't be used (and might not even be compiled in?).

> Thanks.
>
> Max Rupplin
>
> Software Engineer



From Alan.Bateman at oracle.com  Mon Aug 27 06:52:55 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 07:52:55 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
Message-ID: <91acd996-cde3-6131-6938-0958792ae087@oracle.com>

On 14/08/2018 15:07, Stephen Colebourne wrote:
> A new method MethodHandles.Lookup defineClass() was added recently.
> But what about a defineResource? For adding a new resource to the
> classpath (such as a .txt file). I just needed such a thing, and
> though undoubtedly rare, all the recommended solutions use reflection
> and setAccessible().
>
It might be useful to expand on your use-case a bit more. It may be that 
you are really just looking to create a ClassLoader that can locate a 
resource that you generate at run-time. Also the mention of core 
reflection and setAccessible isn't clear as they aren't used with resources.

-Alan

From Alan.Bateman at oracle.com  Mon Aug 27 11:29:42 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 12:29:42 +0100
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
 <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
Message-ID: <cabab3bc-bd89-58c5-03d1-f660d3da4988@oracle.com>

On 24/08/2018 14:18, Langer, Christoph wrote:
> Hi R?mi, Hi Peter,
>
> thanks for your quick answers.
>
> What you've suggested, R?mi, is perfectly right. I've updated my webrev. The methods were copied from our old implementation (of a different class) where they were provided as static.
>
> I will also think of using an optional. I'm furthermore wondering if we should provide a method "dimensions()" returning an (optional) java.io.Console.Dimension object that contains both height and width...
>
> Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/
I'm in two minds as to whether this API is the right thing to do. Can 
you expand a bit on how you are using them? There have been several 
requests for additions to the Console API over the years, mostly to 
support formatting or exposing the console encoding, but I don't recall 
anyone looking for the dimensions. Roger is right that it's a bit of a 
slippery slope. As I recall, java.io.Console was deliberately minimized 
for Java SE 6 to focus on password input and avoid introducing an 
extensive API.? In the mean-time, the additional of jshell has exposed 
some of the shorting comings and maybe we should look at exposing just 
enough to support that type of use-case (editing and line history mostly).

As regards the proposal then I think the API docs will need fleshing out 
to define what height and width as the current javadoc isn't clear if it 
means bytes, characters, pixels in whatever font is used for the 
console, or something else. In addition, the javadoc would need to be 
clear that it's just a snaphot of the dimension as it can change at any 
time.

-Alan

From daniel.fuchs at oracle.com  Mon Aug 27 12:10:59 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 Aug 2018 13:10:59 +0100
Subject: (XS) java.logging Level.java minor cleanups
In-Reply-To: <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <5b6f39a5.1c69fb81.77692.3d3c@mx.google.com>
 <22eb5dc7-31d0-b0ce-1fe0-5e2358f11169@oracle.com>
 <DB7PR08MB330765C5D429A388DBC698BFFF370@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <af1197dd-b640-ea5e-b6a3-bfe4ee5b3eab@oracle.com>

Hi Bernd,

It's in:

https://bugs.openjdk.java.net/browse/JDK-8209987
http://hg.openjdk.java.net/jdk/jdk/rev/5f40be158613

best regards,

-- daniel

On 23/08/2018 20:49, Bernd Eckenfels wrote:
> Yes, Seeburger AG OCA should be on file (b.eckenfels at seeburger.de)
> 
> Thanks for following up
> 
> Did you had any opinion on the synthetic accessors as well?
> Gru?
> Bernd
> 
> -- 
> https://Bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* Daniel Fuchs <daniel.fuchs at oracle.com>
> *Gesendet:* Donnerstag, August 23, 2018 11:20 AM
> *An:* Bernd Eckenfels; core-libs-dev at openjdk.java.net
> *Betreff:* Re: (XS) java.logging Level.java minor cleanups
> Hi Bernd,
> 
> Good finding! I agree with the proposed cleanup.
> I am always a bit uneasy of touching these classes
> as they have a propensity to come back and bite you
> from behind when you're not looking ;-)
> 
> I have applied your patch and sent it to our test system
> for more confidence and everything went well.
> 
> I'll happily sponsor your patch.
> You did sign the OCA - right?
> 
> MfG,
> 
> -- daniel
> 
> On 11/08/2018 20:31, Bernd Eckenfels wrote:
>  > Hello,
>  >
>  > while investigating a Memory leak fix from IBM (IJ05380 is in 
> 8.0.5.20 but not in 8u yet) I noticed that the (fixed) code 
> registerWithClassLoader(Level) in the master queries a unused class name 
> (pn) and it can use the method reference instead of Lambda. See patch 
> below.
>  >
>  > There seems to be also a opportunity to use computeIfAbsent in a 
> unrelated method add(Level), not sure if this is wanted, what do you think?
>  >
>  >
>  > index dbc27124d33..401c6dc73e0 100644
>  > --- a/src/java.logging/share/classes/java/util/logging/Level.java
>  > +++ b/src/java.logging/share/classes/java/util/logging/Level.java
>  > @@ -610,10 +610,7 @@ public class Level implements 
> java.io.Serializable {
>  > }
>  >
>  > private static void registerWithClassLoader(Level customLevel) {
>  > - PrivilegedAction<ClassLoader> pa =
>  > - () -> customLevel.getClass().getClassLoader();
>  > - PrivilegedAction<String> pn = customLevel.getClass()::getName;
>  > - final String name = AccessController.doPrivileged(pn);
>  > + PrivilegedAction<ClassLoader> pa = 
> customLevel.getClass()::getClassLoader;
>  > final ClassLoader cl = AccessController.doPrivileged(pa);
>  > CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
>  > .add(customLevel);
>  > @@ -624,19 +621,10 @@ public class Level implements 
> java.io.Serializable {
>  > // the mirroredLevel object is always added to the list
>  > // before the custom Level instance
>  > KnownLevel o = new KnownLevel(l);
>  > - List<KnownLevel> list = nameToLevels.get(l.name);
>  > - if (list == null) {
>  > - list = new ArrayList<>();
>  > - nameToLevels.put(l.name, list);
>  > - }
>  > - list.add(o);
>  > -
>  > - list = intToLevels.get(l.value);
>  > - if (list == null) {
>  > - list = new ArrayList<>();
>  > - intToLevels.put(l.value, list);
>  > - }
>  > - list.add(o);
>  > + nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
>  > + .add(o);
>  > + intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
>  > + .add(o);
>  >
>  > // keep the custom level reachable from its class loader
>  > // This will ensure that custom level values are not GC'ed
>  >
>  >
>  > I am happy if anyone can sponsor this change.
>  >
>  > BTW: I get a synthetic Accessor warning on l.name/value, is this what 
> nestmates will resolve ? is it worth adjusting the modifiers for those 
> fields anyway?
>  >
>  > Gruss
>  > Bernd
>  >
> 


From Alan.Bateman at oracle.com  Mon Aug 27 13:45:05 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 14:45:05 +0100
Subject: RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
In-Reply-To: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
References: <b9dc8f4e-263c-50bf-e16d-ef1efbece0cb@oracle.com>
Message-ID: <309f8f6a-72ab-e581-365d-cd7f02971ba6@oracle.com>



On 23/08/2018 15:09, Claes Redestad wrote:
> Hi,
>
> it's a tiny startup improvement to rearrange code so that the 
> ExpiringCaches used in the FileSystem implementations aren't created 
> if they aren't going to be used:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209837
>
> 3 fewer classes loaded on bootstrap.
This looks good. A minor nit is the inconsistently long line L244, it 
would be better to keep it consistent with the existing code.

-Alan

From Alan.Bateman at oracle.com  Mon Aug 27 13:52:07 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 14:52:07 +0100
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <69b2a09539384016b890e64e71700809@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
Message-ID: <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>

On 24/08/2018 15:52, Baesken, Matthias wrote:
> Hello, I created another webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
>
> - use now  jarPath  instead of  jarpath  in the java security file
> -  moved the parsing of the property  to a more general location (separate class jdk/internal/util/SecuritySystemPropertyHelper.java  )
> -  read now  from the InputStream and check for error conditions *before*  setting jarFilename    in the Manifest  constructor
>
Will sun.net.util.SocketExceptions be changed to use the supporting 
class or is that a separate issue?

In terms of approach then I think what you have is okay although I think 
we should try to find a better name than "SecuritySystemPropertyHelper" 
and also get feedback from security-dev on whether they would prefer it 
in the sun.security tree with the other classes security classes.

-Alan

From volker.simonis at gmail.com  Mon Aug 27 13:53:01 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 27 Aug 2018 15:53:01 +0200
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
Message-ID: <CA+3eh1114qD9+vM2TymPeaLdAfSJ3YC_2umC2TQJ9OtTo+HeMw@mail.gmail.com>

Hi Brian,

sorry, I'm a little late in the game. I've just looked at your change
and in general it looks good!

There's one thing however I think you still have to fix. After
changing 'stat64' to 'stat' in UnixFileSystem_md.c you should define
'stat' to 'stat64' on AIX if you don't want to change the current
behavior:

$ hg diff
diff -r 8455a2fda5a8 src/java.base/unix/native/libjava/UnixFileSystem_md.c
--- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
Aug 27 11:30:50 2018 +0200
+++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
Aug 27 14:55:07 2018 +0200
@@ -59,6 +59,7 @@
   #define opendir opendir64
   #define readdir readdir64
   #define closedir closedir64
+  #define stat stat64
 #endif

 #if defined(__solaris__) && !defined(NAME_MAX)

The build and first tests with this addition look good. I'll also put
the fix into our nightly queue to run some more extensive tests and
let you know the results tomorrow.

Thank you and best regards,
Volker


On Fri, Aug 24, 2018 at 8:01 PM, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> This one could still use a Reviewer approval or rejection.
>
> Thanks,
>
> Brian
>
> On Aug 14, 2018, at 1:34 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> Hi Bernard,
>>
>> On Aug 14, 2018, at 4:13 AM, B. Blaser <bsrbnd at gmail.com> wrote:
>>
>>> Seems quite good to me, last notes:
>>>
>>> 1) dealing with 'stat/stat64' in 'UnixFileSystem_md.c' might be
>>> outside the scope of this fix (?) even if fully pertinent per [1].
>>
>> It might be slightly out of scope but I think it?s OK as stat64 was defined inside an
>> #if defined(_ALLBSD_SOURCE) conditional compilation block.
>>
>>> In the same file, I think '#define dirent dirent64' is probably missing
>>> for AIX.
>>
>> Fixed.
>>
>>> 2) I guess '#if defined(_AIX) ...' is now missing in 'OperatingSystemImpl.c':
>>> #if defined(_AIX)
>>>  #define DIR DIR64
>>>  #define dirent dirent64
>>>  #define opendir opendir64
>>>  #define readdir readdir64
>>>  #define closedir closedir64
>>> #endif
>>
>> Fixed.
>>
>> Webrev updated in place: http://cr.openjdk.java.net/~bpb/8207744/webrev.04/.
>>
>> Checks out on Linux-x64, macOS, Solaris-sparcv9, Windows-x64.
>>
>>> You'll probably need some more reviews especially for other systems
>>> than Linux 64-bit.
>>
>> It would not hurt. In any case I do not yet have a Reviewer approval.
>>
>> Thanks,
>>
>> Brian
>

From maurizio.cimadamore at oracle.com  Mon Aug 27 14:07:45 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 27 Aug 2018 15:07:45 +0100
Subject: RFR 8209064: Make intellij support more robust after changes for
 2018.2
In-Reply-To: <f5543acc-22ba-1f01-2ff1-4ab5f2502038@oracle.com>
References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>
 <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com>
 <f5543acc-22ba-1f01-2ff1-4ab5f2502038@oracle.com>
Message-ID: <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com>

As I was about to push this, I realize there was a minor nit with the 
way in which build.xml files found some classes inside the generated 
.idea folder - that is, the path to this folder was defined in a 
relative way from the location of the script file.

A more robust way to get there is to setup an idea.dir ant variable 
which is dynamically populated by the IDE with the known location of the 
project IML file.

The only files touched were the two project build.xml files, as well as 
the idea ant.xml files.

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8209064_v2

Maurizio


On 23/08/18 14:21, Maurizio Cimadamore wrote:
>
>
> On 21/08/18 10:31, Magnus Ihse Bursie wrote:
>> Hi Maurizio!
>>
>> Even if this only incidentally relates to the build, please always 
>> include build-dev when making changes in the "make" directory.
> I will - thanks
>>
>> As far as I can understand, your changes looks good. One question: 
>> the build.xml was previously stored as a "template", and copied to 
>> the output directory. Now it's left in the source tree. I assume that 
>> there was no actual transformations or changes made to the template 
>> before? So that the scripts do not modify the source tree version, 
>> that is.
> You are correct - the script is not meant to be modified; customized 
> properties are injected by the runtime environment - such properties 
> are defined in the ant.xml file and that is indeed a template file (so 
> it can be customized).
>
> Thanks
> Maurizio
>>
>> /Magnus
>>
>> On 2018-08-07 13:21, Maurizio Cimadamore wrote:
>>> Hi,
>>> last week I submitted an 'emergency' patch to fix intellij project 
>>> support after 2018.2 changes. The goal of these changes was to move 
>>> the build.xml ant file out of the .idea folder, as the IDE no longer 
>>> supported DOM indexing in such folders (as a result of 
>>> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, 
>>> I tweaked the scripts to copy build.xml in the build folder.
>>>
>>> Thinking more about this issue, there's a more robust fix possible, 
>>> which doesn't involve moving files to the build folder (which could 
>>> be potentially unreliable, depending on how people build the JDK). 
>>> In fact, the best solution is to leave build.xml where it is, and 
>>> fix the remaining configuration files to point at it. This allows to 
>>> revert all changes in the scripts that set up the project 
>>> configuration (bin/idea.sh for JDK, and make/langtools/build.xml for 
>>> langtools).
>>>
>>> For the langtools project a bit more changes were necessary, given 
>>> that in langtools we did not have a 'template' folder - and all 
>>> intellij files were dumped onto the same path. So I had to move the 
>>> configuration langtools files (all but build.xml) under a new 
>>> template folder (located under make/langtools/intellij/make) and 
>>> place build.xml outside it. Then tweak the build.xml script to work 
>>> off this new template folder. These are all small conceptual 
>>> changes, but the impact on the webrev is quite biggie (because of 
>>> file renaming etc.).
>>>
>>> I also took the chance to fix some issues with the JDK project ANT 
>>> configuration (see changes in make/idea/template/workspace.xml), as 
>>> the last changes did not update the location of the ant file used 
>>> here - as a result no ant target entries were showing up under the 
>>> Build menu.
>>>
>>> Webrev here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8209064/
>>>
>>> Cheers
>>> Maurizio
>>>
>>
>


From matthias.baesken at sap.com  Mon Aug 27 14:25:05 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 27 Aug 2018 14:25:05 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
Message-ID: <46322abe1477459cad6ea342950b2da4@sap.com>

Hi Alan ,

> Will sun.net.util.SocketExceptions be changed to use the supporting
> class or is that a separate issue?
> 

I think this is a separate issue .

> In terms of approach then I think what you have is okay although I think
> we should try to find a better name than "SecuritySystemPropertyHelper"
> and also get feedback from security-dev on whether they would prefer it
> in the sun.security tree with the other classes security classes.

Suggestions are welcome , I  was a bit unsure about the name as well ?? !

Thanks, Matthias


> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Montag, 27. August 2018 15:52
> To: Baesken, Matthias <matthias.baesken at sap.com>; Sean Mullan
> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>
> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
> dev at openjdk.java.net>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> On 24/08/2018 15:52, Baesken, Matthias wrote:
> > Hello, I created another webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
> >
> > - use now  jarPath  instead of  jarpath  in the java security file
> > -  moved the parsing of the property  to a more general location (separate
> class jdk/internal/util/SecuritySystemPropertyHelper.java  )
> > -  read now  from the InputStream and check for error conditions *before*
> setting jarFilename    in the Manifest  constructor
> >
> Will sun.net.util.SocketExceptions be changed to use the supporting
> class or is that a separate issue?
> 
> In terms of approach then I think what you have is okay although I think
> we should try to find a better name than "SecuritySystemPropertyHelper"
> and also get feedback from security-dev on whether they would prefer it
> in the sun.security tree with the other classes security classes.
> 
> -Alan

From pavel.rappo at oracle.com  Mon Aug 27 14:33:31 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 27 Aug 2018 15:33:31 +0100
Subject: Reactive Streams utility API
In-Reply-To: <CABY0rKOqgDhtXTJ_=zgFq+H0-V3te_04P1OtHZMUfASdBk-6mA@mail.gmail.com>
References: <CABY0rKP+jdHuvSjp9rMksgCrcWHNYLkcQMz0X=oF=ARW6EBDxg@mail.gmail.com>
 <CABY0rKPKd7W60k0qyX=RB6V=P=CH2YxUry-=9-tyqmERjWpEoA@mail.gmail.com>
 <dae7fffe-7639-ab6b-0f15-5b8517f4397a@oracle.com>
 <CABY0rKMOG_Qq-zCJ6utLFfKitwTEettj45tWr_65RSrFymDGAw@mail.gmail.com>
 <CABY0rKOqgDhtXTJ_=zgFq+H0-V3te_04P1OtHZMUfASdBk-6mA@mail.gmail.com>
Message-ID: <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>

Hi James,

What's the status of the project? Has it been abandoned?

-Pavel

> On 22 Mar 2018, at 00:09, James Roper <james at lightbend.com> wrote:
> 
> Hi all,
> 
> We've created a reference implementation. It's been done in such a way that
> implementation of new features (stages) is quite straight forward, there is
> an abstraction that does the hard work of handling concurrency, the
> reactive streams spec conformance, and managing demand and buffering, and
> error handling, and then individual stages (eg, map, filter, flatMap) are
> implemented using a very easy to use API (note, this API/abstraction is all
> private, internal to the reference implementation). Rudimentary tests on
> performance show that it's not terrible compared to other reactive streams
> implementations, with a number of clear optimization paths identified
> should we decide that's necessary. I believe this proposal is now close to
> complete - the remaining work is:
> 
> * Decide what scope beyond JDK8 streams it should support - while this
> decision is not trivial, the amount of work required to actually add these
> to the API and implement in the reference implementation is trivial.
> * Fill out the TCK with more rigorous verification.
> * Create some rigorous benchmarks.
> 
> I'm not sure what should be done next. I have talked to a number of people
> who are either involved in, or are writing APIs that use Reactive Streams
> in private, and interest seems high. Also, there is general consensus in
> public discussions in the Jakarta EE/MicroProfile communities that an API
> like this would be very valuable in the JDK. The API of course could be
> done in Jakarta EE instead, but given that Reactive Streams is part of and
> used by the JDK, and given that the JDK8 Streams API is part of the JDK,
> Jakarta EE would seem an odd place to put this library - it essentially
> would mean that to make effective use of JDK libraries that use Reactive
> Streams (eg HTTP client, possibly java.sql2 aka ADBA), you need to use
> Jakarta EE (or some third party streaming library).
> 
> So unless there's any major feedback coming here on this list, I'd like to
> put this forward as a JEP.
> 
> Regards,
> 
> James
> 
> On 15 March 2018 at 12:24, James Roper <james at lightbend.com> wrote:
> 
>> Hi all,
>> 
>> An update on this. We've now filled out the API with feature parity with
>> the JDK8 Streams API - for operators that make sense in Reactive Streams.
>> We've provided example implementations of the API backed by both Akka
>> Streams and rxjava, showing that it can be widely implemented. The TCK
>> still needs some work, but covers the major features, and comprehensively
>> covers all publishers/subscribers with the Reactive Streams TCK (so
>> comprehensive that we actually found two Reactive Streams TCK violations in
>> Akka Streams with this, and a couple in rxjava too).
>> 
>> There are two major areas of work left to get something that would be
>> ready to be a candidate for a final API. The first is to produce a zero
>> dependency reference implementation of the API. This is what I plan on
>> starting on next.
>> 
>> The second is to decide what additional operators and generators the API
>> should provide. So far, the scope has been mostly limited to a subset of
>> the JDK8 Streams scope, only a few additional API pieces have been created,
>> such as a few variations on flatMap (one that supports CompletionStage, and
>> one that supports Iterable). There are a number of other features for
>> consideration to provide basic necessary functionality for this API, here's
>> some examples off the top of my head (some of these can already be
>> implemented in terms of other stages already provided):
>> 
>> * A cancelled subscriber (useful for cleaning up hot publishers)
>> * An ignoring subscriber (useful when you do the actual work in a previous
>> stage of the graph, such as mapping to completion stages)
>> * Error handling subscribers and/or processors
>> * Termination listening subscribers and/or processors
>> * A processor that wraps a subscriber and publisher
>> * The ability to merge streams - so far only concat is provided, and all
>> flatMaps are essentially concatenations, merge variants may be useful
>> (though introduce a lot of complexity, such as specifying breadth)
>> * The ability to split streams into sub streams - a use case for this is
>> in parsing a stream that contains potentially large sub streams, like
>> parsing a multipart/form-data body
>> * Batching of elements in a stream, based on predicate, influenced by
>> backpressure or based on a scheduled tick
>> * Scheduled features such as emitting ticks, rate limiting, etc
>> * The ability to control buffering and asynchronous boundaries within a
>> graph
>> * Naming of stages for debug/error reporting/monitoring purposes
>> 
>> Not all of the above may be absolutely necessary, but should be
>> considered, and there may be other features as well that would be useful to
>> consider.
>> 
>> Please visit the repo and any feedback would be much appreciated:
>> 
>> https://github.com/lightbend/reactive-streams-utils
>> 
>> Regards,
>> 
>> James
>> 
>> On 8 March 2018 at 03:59, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>>> To answer the questions at the bottom: the next step is to start working
>>> on this and get folks excited about contributing.  There's plenty of time
>>> for process later, but filing a JEP or creating a project shouldn't be a
>>> barrier to innovating.
>>> 
>>> 
>>> On 2/28/2018 10:33 PM, James Roper wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> We've put together a simple proposal for this. Please read the README for
>>>> an introduction to this proposal.
>>>> 
>>>> https://github.com/lightbend/reactive-streams-utils
>>>> 
>>>> Regards,
>>>> 
>>>> James
>>>> 
>>>> On 22 February 2018 at 11:47, James Roper <james at lightbend.com> wrote:
>>>> 
>>>> Hi all,
>>>>> 
>>>>> This is an email to give people a heads up that we'd like to look at
>>>>> creating an API, in the same vein as the JDK8 Streams API, for building
>>>>> reactive streams (a la JDK9 juc.Flow). Our goals for this are:
>>>>> 
>>>>> * To fill a gap in the JDK where if a developer wants to do even the
>>>>> simplest of things with a JDK9 juc.Flow, such as map or filter, they
>>>>> need
>>>>> to bring in a third party library that implements that.
>>>>> * To produce an API that can build Publishers, Subscribers, Processors,
>>>>> and complete graphs, for the purposes of consuming APIs that use
>>>>> reactive
>>>>> streams (for example, JDK9 Http Client).
>>>>> * To produce an API that aligns closely with ju.stream.Stream, using it
>>>>> for inspiration for naming, scope, general API shape, and other aspects.
>>>>> The purpose of this goal is to ensure familiarity of Java developers
>>>>> with
>>>>> the new API, and to limit the number of concepts Java developers need to
>>>>> understand to do the different types of streaming offered by the JDK.
>>>>> * To produce an API that can be implemented by multiple providers
>>>>> (including an RI in the JDK itself), using the ServiceLoader mechanism
>>>>> to
>>>>> provide and load a default implementation (while allowing custom
>>>>> implementations to be manually provided). There are a lot of concerns
>>>>> that
>>>>> each different streams implementation provides and implements, beyond
>>>>> streaming, for example monitoring/tracing, concurrency modelling,
>>>>> buffering
>>>>> strategies, performance aspects of the streams handling including
>>>>> fusing,
>>>>> and context (eg thread local) propagation. This will allow libraries to
>>>>> use
>>>>> and provide contracts based on this API without depending on a
>>>>> particular
>>>>> implementation, and allows developers to select the implementation that
>>>>> meets their needs.
>>>>> 
>>>>> Non goals:
>>>>> 
>>>>> * To produce a kitchen sink of utilities for working with reactive
>>>>> streams. There already exist a number of reactive streams
>>>>> implementations
>>>>> that seek to meet this goal (eg, Akka Streams, Reactor, RxJava), and
>>>>> once
>>>>> you go past the basics (map, filter, collect), and start dealing with
>>>>> things like fan in/out, cycles, restarting, etc, the different
>>>>> approaches
>>>>> to solving this start to vary greatly. The JDK should provide enough to
>>>>> be
>>>>> useful for typical every day streaming use cases, with developers being
>>>>> able to select a third party library for anything more advanced.
>>>>> 
>>>>> We will update this list when we have something ready for public review.
>>>>> This probably won't be far off. Our hope is that we can propose this as
>>>>> a
>>>>> JEP.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> James
>>>>> 
>>>>> --
>>>>> *James Roper*
>>>>> *Senior Octonaut*
>>>>> 
>>>>> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
>>>>> Twitter: @jroper <https://twitter.com/jroper>
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> --
>> *James Roper*
>> *Senior Octonaut*
>> 
>> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
>> Twitter: @jroper <https://twitter.com/jroper>
>> 
> 
> 
> 
> -- 
> *James Roper*
> *Senior Octonaut*
> 
> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>


From Alan.Bateman at oracle.com  Mon Aug 27 14:41:16 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 15:41:16 +0100
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
Message-ID: <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>

On 24/08/2018 18:27, David Lloyd wrote:
> Why not go ahead and implement getResource as well?  It's not *that*
> big of a deal to add a URL handler, and it would be a fairly trivial
> one.
Right, it wouldn't be too hard but it would require a bit of plumbing to 
have it backed by the Memory* classes in the source file launcher. That 
said, a newbie starting out with "java HelloWorld.java" is unlikely to 
be writing code that needs the class bytes so it's more likely the more 
advanced cases where the code is using a library that needs the bytes.

-Alan

From david.lloyd at redhat.com  Mon Aug 27 14:47:43 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 27 Aug 2018 09:47:43 -0500
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
Message-ID: <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>

On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 24/08/2018 18:27, David Lloyd wrote:
> > Why not go ahead and implement getResource as well?  It's not *that*
> > big of a deal to add a URL handler, and it would be a fairly trivial
> > one.
> Right, it wouldn't be too hard but it would require a bit of plumbing to
> have it backed by the Memory* classes in the source file launcher. That
> said, a newbie starting out with "java HelloWorld.java" is unlikely to
> be writing code that needs the class bytes so it's more likely the more
> advanced cases where the code is using a library that needs the bytes.

AFAIK any code would expect that resources available as streams would
generally also be available as URLs.  I'm not sure that distinguishing
between basic and advanced code really clarifies anything in terms of
the question.

-- 
- DML

From weijun.wang at oracle.com  Mon Aug 27 15:34:39 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 27 Aug 2018 23:34:39 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <46322abe1477459cad6ea342950b2da4@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
Message-ID: <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>



> On Aug 27, 2018, at 10:25 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Alan ,
> 
>> Will sun.net.util.SocketExceptions be changed to use the supporting
>> class or is that a separate issue?
>> 
> 
> I think this is a separate issue .
> 
>> In terms of approach then I think what you have is okay although I think
>> we should try to find a better name than "SecuritySystemPropertyHelper"
>> and also get feedback from security-dev on whether they would prefer it
>> in the sun.security tree with the other classes security classes.
> 
> Suggestions are welcome , I  was a bit unsure about the name as well ?? !

I am OK with creating a sun.security.util.SecurityProperties class, and a method called privilegeGetOverridable() for the 1st part of SecuritySystemPropertyHelper::initTextProperty (by overridable I mean a system property can shadow the security property). I have no idea where the 2nd part should go. Maybe you can just create an includedInExceptions(String refName) method for this purpose.

So it will be something like this

public class SecurityProperties {

    public static String privilegeGetOverridable(String propName) {
        return AccessController.doPrivileged((PrivilegedAction<String>)
                () -> {
                    String val = System.getProperty(propName);
                    if (val == null) {
                        return Security.getProperty(propName);
                    } else {
                        return val;
                    }
                });
    }

    public static boolean includedInExceptions(String refName) {
        String val = privilegeGetOverridable("jdk.includeInExceptions");
        if (val == null){
            return false;
        }
        String[] tokens = val.split(",");
        for (String token : tokens) {
            if (token.equalsIgnoreCase(refName))
                return true;
        }
        return false;
    }
}

Thanks
Max


> 
> Thanks, Matthias
> 
> 
>> -----Original Message-----
>> From: Alan Bateman <Alan.Bateman at oracle.com>
>> Sent: Montag, 27. August 2018 15:52
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Sean Mullan
>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
>> dev at openjdk.java.net>
>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>> 
>> On 24/08/2018 15:52, Baesken, Matthias wrote:
>>> Hello, I created another webrev :
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
>>> 
>>> - use now  jarPath  instead of  jarpath  in the java security file
>>> -  moved the parsing of the property  to a more general location (separate
>> class jdk/internal/util/SecuritySystemPropertyHelper.java  )
>>> -  read now  from the InputStream and check for error conditions *before*
>> setting jarFilename    in the Manifest  constructor
>>> 
>> Will sun.net.util.SocketExceptions be changed to use the supporting
>> class or is that a separate issue?
>> 
>> In terms of approach then I think what you have is okay although I think
>> we should try to find a better name than "SecuritySystemPropertyHelper"
>> and also get feedback from security-dev on whether they would prefer it
>> in the sun.security tree with the other classes security classes.
>> 
>> -Alan


From martinrb at google.com  Mon Aug 27 16:25:51 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Aug 2018 09:25:51 -0700
Subject: RFR: 8209937: Enhance java.io.Console - provide methods to query
 console width and height
In-Reply-To: <cabab3bc-bd89-58c5-03d1-f660d3da4988@oracle.com>
References: <092fc7b85e0042a18261723ec7488879@sap.com>
 <1001576142.713792.1535105387871.JavaMail.zimbra@u-pem.fr>
 <da6c41c1-27e4-1dcc-8bff-2147c7507199@gmail.com>
 <9bf430f6a8a6430ea2654ec725a57e9f@sap.com>
 <cabab3bc-bd89-58c5-03d1-f660d3da4988@oracle.com>
Message-ID: <CA+kOe084OUb5EQCL_=DSAWu4zr98SrCarjO1cVWiL0==exOdEw@mail.gmail.com>

History: I was always a little disappointed that Console (understandably)
didn't support the things you could do with subprocesses in Emacs, like
implement shell buffers and otherwise have expect-style conversations with
subprocesses.  But console dimensions was never on my radar - doesn't mean
much in an Emacs shell buffer.  Being able to reimplement Emacs in pure
Java is of course the ever elusive Holy Grail.  Of course, when I run java,
it's usually living inside a shell buffer.

From seth.lytle at gmail.com  Mon Aug 27 17:24:31 2018
From: seth.lytle at gmail.com (seth lytle)
Date: Mon, 27 Aug 2018 13:24:31 -0400
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
Message-ID: <CAJtn+Ad7tG2=3WVE3ya6ipjQDuLV6NZb36B0Z_EEdxpt2KxCYQ@mail.gmail.com>

david lloyd wrote:
> AFAIK any code would expect that resources available as streams would generally
also be available as URLs

starting with java 9, the javadocs for getResource (but not for
getResourceAsStream) specifically allow returning null if "a URL could not
be constructed to locate the resource"

so even if code has some reason to prefer URLs for bytecode, it should know
to check AsStream as well

@david - i believe jon will address your earlier question about the
downside of getResource, so i haven't responded










On Mon, Aug 27, 2018 at 10:47 AM, David Lloyd <david.lloyd at redhat.com>
wrote:

> On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> >
> > On 24/08/2018 18:27, David Lloyd wrote:
> > > Why not go ahead and implement getResource as well?  It's not *that*
> > > big of a deal to add a URL handler, and it would be a fairly trivial
> > > one.
> > Right, it wouldn't be too hard but it would require a bit of plumbing to
> > have it backed by the Memory* classes in the source file launcher. That
> > said, a newbie starting out with "java HelloWorld.java" is unlikely to
> > be writing code that needs the class bytes so it's more likely the more
> > advanced cases where the code is using a library that needs the bytes.
>
> AFAIK any code would expect that resources available as streams would
> generally also be available as URLs.  I'm not sure that distinguishing
> between basic and advanced code really clarifies anything in terms of
> the question.
>
> --
> - DML
>

From jonathan.gibbons at oracle.com  Mon Aug 27 17:37:33 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Aug 2018 10:37:33 -0700
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CAJtn+Ad7tG2=3WVE3ya6ipjQDuLV6NZb36B0Z_EEdxpt2KxCYQ@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
 <CAJtn+Ad7tG2=3WVE3ya6ipjQDuLV6NZb36B0Z_EEdxpt2KxCYQ@mail.gmail.com>
Message-ID: <d81ad99d-8ec8-dc27-1475-9d47b441b1e6@oracle.com>

This is now being tracked in JDK-8210009.

https://bugs.openjdk.java.net/browse/JDK-8210009

-- Jon

On 8/27/18 10:24 AM, seth lytle wrote:
> david lloyd wrote:
>> AFAIK any code would expect that resources available as streams would generally
> also be available as URLs
>
> starting with java 9, the javadocs for getResource (but not for
> getResourceAsStream) specifically allow returning null if "a URL could not
> be constructed to locate the resource"
>
> so even if code has some reason to prefer URLs for bytecode, it should know
> to check AsStream as well
>
> @david - i believe jon will address your earlier question about the
> downside of getResource, so i haven't responded
>
>
>
>
>
>
>
>
>
>
> On Mon, Aug 27, 2018 at 10:47 AM, David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>> On 24/08/2018 18:27, David Lloyd wrote:
>>>> Why not go ahead and implement getResource as well?  It's not *that*
>>>> big of a deal to add a URL handler, and it would be a fairly trivial
>>>> one.
>>> Right, it wouldn't be too hard but it would require a bit of plumbing to
>>> have it backed by the Memory* classes in the source file launcher. That
>>> said, a newbie starting out with "java HelloWorld.java" is unlikely to
>>> be writing code that needs the class bytes so it's more likely the more
>>> advanced cases where the code is using a library that needs the bytes.
>> AFAIK any code would expect that resources available as streams would
>> generally also be available as URLs.  I'm not sure that distinguishing
>> between basic and advanced code really clarifies anything in terms of
>> the question.
>>
>> --
>> - DML
>>


From Alan.Bateman at oracle.com  Mon Aug 27 17:47:26 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 18:47:26 +0100
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
Message-ID: <dbcf2a36-71f9-6776-c592-64d362d45148@oracle.com>

On 27/08/2018 15:47, David Lloyd wrote:
> :
> AFAIK any code would expect that resources available as streams would
> generally also be available as URLs.  I'm not sure that distinguishing
> between basic and advanced code really clarifies anything in terms of
> the question.
>
I think you've mis-read my mail. I was just observing that newbie/simple 
programs executed by the source file launcher are unlikely to need to 
locate the class bytes via the getResourceXXX APIs. That doesn't mean 
the issue should be ignored, it just means it may not be high priority. 
In any case, I see Jon has created an issue to track this. Also the URL 
protocol handler pluggability that was added in Java SE 9 will help as 
it makes me it easy for the jdk.compiler module to include a 
URLStreamHandlerProvider.

-Alan

From jonathan.gibbons at oracle.com  Mon Aug 27 17:49:50 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Aug 2018 10:49:50 -0700
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <dbcf2a36-71f9-6776-c592-64d362d45148@oracle.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
 <dbcf2a36-71f9-6776-c592-64d362d45148@oracle.com>
Message-ID: <86c51530-78a0-0cb1-5556-167d0336cffc@oracle.com>



On 8/27/18 10:47 AM, Alan Bateman wrote:
> On 27/08/2018 15:47, David Lloyd wrote:
>> :
>> AFAIK any code would expect that resources available as streams would
>> generally also be available as URLs.? I'm not sure that distinguishing
>> between basic and advanced code really clarifies anything in terms of
>> the question.
>>
> I think you've mis-read my mail. I was just observing that 
> newbie/simple programs executed by the source file launcher are 
> unlikely to need to locate the class bytes via the getResourceXXX 
> APIs. That doesn't mean the issue should be ignored, it just means it 
> may not be high priority. In any case, I see Jon has created an issue 
> to track this. Also the URL protocol handler pluggability that was 
> added in Java SE 9 will help as it makes me it easy for the 
> jdk.compiler module to include a URLStreamHandlerProvider.
>
> -Alan
Alan,

It looks like we don't even need to register a URLStreamHandlerProvider, 
we can provide the URLStreamHandler when we create the URL. :-)

-- Jon

From peter.levart at gmail.com  Mon Aug 27 17:51:46 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 27 Aug 2018 19:51:46 +0200
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
Message-ID: <01b7c49c-eaea-cbda-1e86-e143c15df9ad@gmail.com>



On 08/27/2018 04:47 PM, David Lloyd wrote:
> On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 24/08/2018 18:27, David Lloyd wrote:
>>> Why not go ahead and implement getResource as well?  It's not *that*
>>> big of a deal to add a URL handler, and it would be a fairly trivial
>>> one.
>> Right, it wouldn't be too hard but it would require a bit of plumbing to
>> have it backed by the Memory* classes in the source file launcher. That
>> said, a newbie starting out with "java HelloWorld.java" is unlikely to
>> be writing code that needs the class bytes so it's more likely the more
>> advanced cases where the code is using a library that needs the bytes.
> AFAIK any code would expect that resources available as streams would
> generally also be available as URLs.  I'm not sure that distinguishing
> between basic and advanced code really clarifies anything in terms of
> the question.
>

Maybe there's a middle ground where URLStreamHandlerProvider is not 
provided. In other words, one would not be able to "parse" URL(s) from 
String(s) such that those URL(s) would be usable in providing the 
content via openConnection().getInputStream(). Such a thing would be 
very hard to achieve anyway as one can think of situations where there's 
more than one MemoryClassLoader instance present in a single JVM (for 
example, some java source launched via java launcher uses tools API to 
instruct "java" tool to launch another java source file). In such 
situation one would have to distinguish URL(s) resolving resources of 
one MemoryClassLoader from URL(s) resolving resources of another 
MemoryClassLoader. In other words, URL scheme would have to contain some 
identification of MemoryClassLoader instance and MemoryClassLoader 
instances would have to be registered in a JVM global Map<UUID, 
WeakReference<MemoryClassLoader>> for example, etc, etc... Just imagine 
the complexity of a full-blown solution.

There's a middle ground where MemoryClassLoader.getResource() returns a 
URL which is usable in providing the content such that 
url.openConnection() returns an URLConnection and such 
urlConnection.getInputStream() returns an InputStream providing the 
class bytes. One can even construct URL(s) by providing some URL 
obtained by getResource() and resolving against it, effectively 
targeting the choosen MemoryClassLoader instance. Here's such prototype 
for illustration:

http://cr.openjdk.java.net/~plevart/jdk-dev/MemoryClassLoader_getResource/webrev.01/

Running: java Test.java with the following source:


import java.io.InputStream;
import java.net.URL;
import java.net.URLConnection;

public class Test {
 ??? public static void main(String[] args) throws Exception {
 ??????? String name = Test.class.getName().replace('.', '/') + ".class";
 ??????? URL url = Test.class.getClassLoader().getResource(name);
 ??????? System.out.println("URL: " + url);
 ??????? URLConnection conn = url.openConnection();
 ??????? System.out.println("Content-Length: " + conn.getContentLength());
 ??????? System.out.println("Content-Type: " + conn.getContentType());
 ??????? InputStream in = conn.getInputStream();
 ??????? byte[] bytes = in.readAllBytes();
 ??????? System.out.println("bytes.length: " + bytes.length);
 ??? }
}


Prints the following:


URL: classbytes:/Test.class
Content-Length: 1763
Content-Type: application/octet-stream
bytes.length: 1763


Would that be enough for bytecode instrumentation tools?

Regards, Peter


From philip.race at oracle.com  Mon Aug 27 17:53:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 27 Aug 2018 10:53:27 -0700
Subject: [12] Review Request: 8205537 Drop of sun.applet package
In-Reply-To: <ed6f1586-754d-efc7-a41a-65311e8b6ae9@oracle.com>
References: <ed6f1586-754d-efc7-a41a-65311e8b6ae9@oracle.com>
Message-ID: <60a579e8-0311-5dce-23cd-b393f24fc5a9@oracle.com>

- * @summary Checks that SwingLazyValue class correclty works
+ * @summary Checks that SwingLazyValue class correctly works


And "correctly works" should be "works correctly"

For test/jdk/sun/misc/URLClassPath/ClassnameCharTest.java
please add a comment that the class loader code was
copied from the now deleted AppletClassLoader.

I don't need to see an updated webrev for those minor changes.

-phil.

On 7/31/2018 4:39 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8205537
> Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/
>
> sun.applet is an internal package contained some code related to
> implementation of applets and appletviewer. Some of its classes were
> dropped already: JDK-8204454, JDK-8203308. Now there are only 3 classes,
> all related to the applet security and we can drop them as well.
>
> In the fix this package was removed, and the tests were updated to not
> use it. I am not sure how "ClassnameCharTest.java" is useful after
> applets removal, but since this test used subclass of the
> AppletClassLoader, I have copied some code from the removed class to the
> test.
>


From Alan.Bateman at oracle.com  Mon Aug 27 18:09:24 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Aug 2018 19:09:24 +0100
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <86c51530-78a0-0cb1-5556-167d0336cffc@oracle.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
 <dbcf2a36-71f9-6776-c592-64d362d45148@oracle.com>
 <86c51530-78a0-0cb1-5556-167d0336cffc@oracle.com>
Message-ID: <1dbd1096-9c76-78b1-6d47-8d5c570a6ce0@oracle.com>

On 27/08/2018 18:49, Jonathan Gibbons wrote:
>
> Alan,
>
> It looks like we don't even need to register a 
> URLStreamHandlerProvider, we can provide the URLStreamHandler when we 
> create the URL. :-)
This will only work for URL objects returned by getResource. If you 
create the URL by other means, and without specifying the 
URLStreamHandler, then the URL constructor will fail as the protocol 
won't be known.

-Alan.

From jonathan.gibbons at oracle.com  Mon Aug 27 18:18:26 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Aug 2018 11:18:26 -0700
Subject: JEP 330 class loader getResourceAsStream
In-Reply-To: <01b7c49c-eaea-cbda-1e86-e143c15df9ad@gmail.com>
References: <CAJtn+Acqq4kBBsLxJDgKOynotXYMYY63zLupOUXNXma86WqGNw@mail.gmail.com>
 <CANghgrRS3mfQc1yXhGh--Sftai_ZV13FxTKJ_xfbPr7GE-FyWQ@mail.gmail.com>
 <f98c8fc9-afe5-88f0-0d64-84a997e8c7aa@oracle.com>
 <CANghgrSr8sdLvVa4SS67aos+7htRuK3kRSEbGDWjTyLbBNmazw@mail.gmail.com>
 <01b7c49c-eaea-cbda-1e86-e143c15df9ad@gmail.com>
Message-ID: <23ebc2eb-8026-902c-ad90-caea6ee1c322@oracle.com>



On 8/27/18 10:51 AM, Peter Levart wrote:
>
>
> On 08/27/2018 04:47 PM, David Lloyd wrote:
>> On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman 
>> <Alan.Bateman at oracle.com> wrote:
>>> On 24/08/2018 18:27, David Lloyd wrote:
>>>> Why not go ahead and implement getResource as well?? It's not *that*
>>>> big of a deal to add a URL handler, and it would be a fairly trivial
>>>> one.
>>> Right, it wouldn't be too hard but it would require a bit of 
>>> plumbing to
>>> have it backed by the Memory* classes in the source file launcher. That
>>> said, a newbie starting out with "java HelloWorld.java" is unlikely to
>>> be writing code that needs the class bytes so it's more likely the more
>>> advanced cases where the code is using a library that needs the bytes.
>> AFAIK any code would expect that resources available as streams would
>> generally also be available as URLs.? I'm not sure that distinguishing
>> between basic and advanced code really clarifies anything in terms of
>> the question.
>>
>
> Maybe there's a middle ground where URLStreamHandlerProvider is not 
> provided. In other words, one would not be able to "parse" URL(s) from 
> String(s) such that those URL(s) would be usable in providing the 
> content via openConnection().getInputStream(). Such a thing would be 
> very hard to achieve anyway as one can think of situations where 
> there's more than one MemoryClassLoader instance present in a single 
> JVM (for example, some java source launched via java launcher uses 
> tools API to instruct "java" tool to launch another java source file). 
> In such situation one would have to distinguish URL(s) resolving 
> resources of one MemoryClassLoader from URL(s) resolving resources of 
> another MemoryClassLoader. In other words, URL scheme would have to 
> contain some identification of MemoryClassLoader instance and 
> MemoryClassLoader instances would have to be registered in a JVM 
> global Map<UUID, WeakReference<MemoryClassLoader>> for example, etc, 
> etc... Just imagine the complexity of a full-blown solution.
>
> There's a middle ground where MemoryClassLoader.getResource() returns 
> a URL which is usable in providing the content such that 
> url.openConnection() returns an URLConnection and such 
> urlConnection.getInputStream() returns an InputStream providing the 
> class bytes. One can even construct URL(s) by providing some URL 
> obtained by getResource() and resolving against it, effectively 
> targeting the choosen MemoryClassLoader instance. Here's such 
> prototype for illustration:
>
> http://cr.openjdk.java.net/~plevart/jdk-dev/MemoryClassLoader_getResource/webrev.01/ 
>
>
> Running: java Test.java with the following source:
>
>
> import java.io.InputStream;
> import java.net.URL;
> import java.net.URLConnection;
>
> public class Test {
> ??? public static void main(String[] args) throws Exception {
> ??????? String name = Test.class.getName().replace('.', '/') + ".class";
> ??????? URL url = Test.class.getClassLoader().getResource(name);
> ??????? System.out.println("URL: " + url);
> ??????? URLConnection conn = url.openConnection();
> ??????? System.out.println("Content-Length: " + conn.getContentLength());
> ??????? System.out.println("Content-Type: " + conn.getContentType());
> ??????? InputStream in = conn.getInputStream();
> ??????? byte[] bytes = in.readAllBytes();
> ??????? System.out.println("bytes.length: " + bytes.length);
> ??? }
> }
>
>
> Prints the following:
>
>
> URL: classbytes:/Test.class
> Content-Length: 1763
> Content-Type: application/octet-stream
> bytes.length: 1763
>
>
> Would that be enough for bytecode instrumentation tools?
>
> Regards, Peter
>

Peter,

I like this form of solution; I like that we can fairly easily return a 
URL, from which the user can get a stream that is equivalent to using 
getResourceAsStream, without having to provide the "full-blown" solution.

-- Jon

From scolebourne at joda.org  Mon Aug 27 21:51:51 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 27 Aug 2018 22:51:51 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
Message-ID: <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>

The specific code was written in Java 8 world to create a ClassLoader
containing the resource with a suitable parent (as a test case). The
resource was accessed using ClassLoader.getResources() from a shared
library. Under Java 9 I've had to change ClassLoader.getResources() to
Class.getResource() in the shared library, which means that creating a
new ClassLoader doesn't work for writing the test. (The relevant code
is now untested, which is far from ideal). See the commit here:
https://github.com/OpenGamma/Strata/commit/8f2d4d32630af2981d167418dab78c8e2fc98a64

The reason for this thread is a realisation that
MethodHandles.Lookup.defineClass() allows a class to be pushed into an
existing ClassLoader & Module, but I'm unaware of an equivalent for
resources, and that seems like a gap, regardless of use case.

The reflection/setAccessible comment refers to articles like this:
https://baptiste-wicht.com/posts/2010/05/tip-add-resources-dynamically-to-a-classloader.html

thanks
Stephen

On Mon, 27 Aug 2018 at 07:53, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 14/08/2018 15:07, Stephen Colebourne wrote:
> > A new method MethodHandles.Lookup defineClass() was added recently.
> > But what about a defineResource? For adding a new resource to the
> > classpath (such as a .txt file). I just needed such a thing, and
> > though undoubtedly rare, all the recommended solutions use reflection
> > and setAccessible().
> >
> It might be useful to expand on your use-case a bit more. It may be that
> you are really just looking to create a ClassLoader that can locate a
> resource that you generate at run-time. Also the mention of core
> reflection and setAccessible isn't clear as they aren't used with resources.
>
> -Alan

From brian.burkhalter at oracle.com  Tue Aug 28 00:26:30 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 27 Aug 2018 17:26:30 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <CA+3eh1114qD9+vM2TymPeaLdAfSJ3YC_2umC2TQJ9OtTo+HeMw@mail.gmail.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
 <CA+3eh1114qD9+vM2TymPeaLdAfSJ3YC_2umC2TQJ9OtTo+HeMw@mail.gmail.com>
Message-ID: <AD719A3D-3C9D-46FD-B3D5-3DDE9B8A700A@oracle.com>

Hi Volker,

On Aug 27, 2018, at 6:53 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> sorry, I'm a little late in the game. I've just looked at your change
> and in general it looks good!

Thanks: better late than never!

> There's one thing however I think you still have to fix. After
> changing 'stat64' to 'stat' in UnixFileSystem_md.c you should define
> 'stat' to 'stat64' on AIX if you don't want to change the current
> behavior:
> 
> $ hg diff
> diff -r 8455a2fda5a8 src/java.base/unix/native/libjava/UnixFileSystem_md.c
> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
> Aug 27 11:30:50 2018 +0200
> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
> Aug 27 14:55:07 2018 +0200
> @@ -59,6 +59,7 @@
>   #define opendir opendir64
>   #define readdir readdir64
>   #define closedir closedir64
> +  #define stat stat64
> #endif
> 
> #if defined(__solaris__) && !defined(NAME_MAX)

Thanks for pointing that out. An updated webrev with this change is at

http://cr.openjdk.java.net/~bpb/8207744/webrev.05/

> The build and first tests with this addition look good. I'll also put
> the fix into our nightly queue to run some more extensive tests and
> let you know the results tomorrow.

I ran this revision through our test system and there were no failures on the platforms we usually test. If your tests succeed then this should be good to go unless there are objections.

Thanks,

Brian

From xu.y.yin at oracle.com  Tue Aug 28 05:50:13 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 28 Aug 2018 13:50:13 +0800
Subject: [12] RFR 8209773: Refactor shell test javax/naming/module/basic.sh to
 java
Message-ID: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>

Please have a review for below change to refactor shell test javax/naming/module/basic.sh to plain java, no test logic change, old shell script is removed at same time, thanks

bug: https://bugs.openjdk.java.net/browse/JDK-8209773
webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/

Regards,
Chris

From peter.levart at gmail.com  Tue Aug 28 06:55:01 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 28 Aug 2018 08:55:01 +0200
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
Message-ID: <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>

Hi Stephen,

On 08/27/2018 11:51 PM, Stephen Colebourne wrote:
> The specific code was written in Java 8 world to create a ClassLoader
> containing the resource with a suitable parent (as a test case). The
> resource was accessed using ClassLoader.getResources() from a shared
> library. Under Java 9 I've had to change ClassLoader.getResources() to
> Class.getResource() in the shared library, which means that creating a
> new ClassLoader doesn't work for writing the test.

I assume that the library had to change to using Class.getResource() 
because it expects the resource to be found in the module containing the 
class if the class is located in a named module or in the usual Class' 
ClassLoader delegating way if it is not. Given that you refer to testing 
the following library method:

 ??? ExampleMarketDataBuilder.ofResource("zip-data", classLoader)

...which takes a ClassLoader parameter, the question is whether the API 
of this method changed from taking a ClassLoader parameter to something 
else and what it changed to. Since the library method now uses 
Class.getResource(), I wonder which Class object it uses. If the Class 
object is now passed to the library method, you could define a class in 
your testing ClassLoader and hand it to the library method. The simplest 
way to define a class in some ClassLoader is by using Proxy API.

>   (The relevant code
> is now untested, which is far from ideal). See the commit here:
> https://github.com/OpenGamma/Strata/commit/8f2d4d32630af2981d167418dab78c8e2fc98a64
>
> The reason for this thread is a realisation that
> MethodHandles.Lookup.defineClass() allows a class to be pushed into an
> existing ClassLoader & Module, but I'm unaware of an equivalent for
> resources, and that seems like a gap, regardless of use case.

ClassLoader (the Java part of it at least, which is exposed as an API) 
is a delegate of a VM. VM calls it when it needs the bytecode of a 
particular class it wants to define lazily. The ClassLoader API is such 
that at the end, the ClassLoader calls back into the VM to define the 
class whose bytecode it obtained in its own way. 
MethodHandles.Lookup.defineClass() in this respect "bypasses" this 
searching mechanism and ClassLoader API entirely and "eagerly" defines a 
class in the VM. ClassLoader API and its bytecode resource searching 
logic is not involved here.

What you are proposing as "defineResource()" API is therefore not a 
parallel of defineClass(). ClassLoader API is all about "searching" for 
resources (bytecode and other kinds) while defineClass() has nothing to 
do with "searching" and everything to do with VM internals. Your 
proposed defineResource() would have nothing to do with VM and 
everything to do with searching as it would just augment the search 
logic of existing ClassLoader instance.

Regards, Peter

> The reflection/setAccessible comment refers to articles like this:
> https://baptiste-wicht.com/posts/2010/05/tip-add-resources-dynamically-to-a-classloader.html
>
> thanks
> Stephen
>
> On Mon, 27 Aug 2018 at 07:53, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 14/08/2018 15:07, Stephen Colebourne wrote:
>>> A new method MethodHandles.Lookup defineClass() was added recently.
>>> But what about a defineResource? For adding a new resource to the
>>> classpath (such as a .txt file). I just needed such a thing, and
>>> though undoubtedly rare, all the recommended solutions use reflection
>>> and setAccessible().
>>>
>> It might be useful to expand on your use-case a bit more. It may be that
>> you are really just looking to create a ClassLoader that can locate a
>> resource that you generate at run-time. Also the mention of core
>> reflection and setAccessible isn't clear as they aren't used with resources.
>>
>> -Alan


From Alan.Bateman at oracle.com  Tue Aug 28 07:17:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Aug 2018 08:17:18 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
Message-ID: <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>

On 28/08/2018 07:55, Peter Levart wrote:
> :
>
> What you are proposing as "defineResource()" API is therefore not a 
> parallel of defineClass(). ClassLoader API is all about "searching" 
> for resources (bytecode and other kinds) while defineClass() has 
> nothing to do with "searching" and everything to do with VM internals. 
> Your proposed defineResource() would have nothing to do with VM and 
> everything to do with searching as it would just augment the search 
> logic of existing ClassLoader instance.
Right, and any class injected with Lookup.defineClass can be located 
with methods such as Class.forName or Lookup.findClass. There is no 
equivalent for resources, at least not without extending the ClassLoader 
API in ways that would work with existing implementations.

On the "Tip : Add resources dynamically to a ClassLoader" link that 
Stephen linked to. That is really a hack, or rather two hacks. The first 
hack is casting the system class loader to a URLClassLoader as that is 
making an assumption on the implementation type. The second is that it 
calls the protected addURL method from the wrong context, which will 
break once java.base is fully encapsulated. Aside from tool agents, it 
doesn't make sense to attempt to extend the class path dynamically link 
this. These articles/tips really need to create a URLClassLoader that 
locates the additional classes/resources and use core reflection to 
load/access them.

-Alan.

From peter.levart at gmail.com  Tue Aug 28 07:17:36 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 28 Aug 2018 09:17:36 +0200
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
Message-ID: <f32f5322-78a0-bc4f-5326-b7d550f2624f@gmail.com>



On 08/28/2018 08:55 AM, Peter Levart wrote:
>> MethodHandles.Lookup.defineClass() allows a class to be pushed into an
>> existing ClassLoader & Module, but I'm unaware of an equivalent for
>> resources, and that seems like a gap, regardless of use case.
>
> ClassLoader (the Java part of it at least, which is exposed as an API) 
> is a delegate of a VM. VM calls it when it needs the bytecode of a 
> particular class it wants to define lazily. The ClassLoader API is 
> such that at the end, the ClassLoader calls back into the VM to define 
> the class whose bytecode it obtained in its own way. 
> MethodHandles.Lookup.defineClass() in this respect "bypasses" this 
> searching mechanism and ClassLoader API entirely and "eagerly" defines 
> a class in the VM. ClassLoader API and its bytecode resource searching 
> logic is not involved here.
>
> What you are proposing as "defineResource()" API is therefore not a 
> parallel of defineClass(). ClassLoader API is all about "searching" 
> for resources (bytecode and other kinds) while defineClass() has 
> nothing to do with "searching" and everything to do with VM internals. 
> Your proposed defineResource() would have nothing to do with VM and 
> everything to do with searching as it would just augment the search 
> logic of existing ClassLoader instance.

...thinking further... In any way, such defineResource() method would 
have to be empty and declared in java.lang.ClassLoder. Why? Because its 
purpose would be to augment the logic of ClassLoader.findResource(s) 
method(s) and those methods are implemented by ClassLoader subclasses. 
Each ClassLoader subclass implements its own particular strategy of 
searching for resources. There's no way to "generically" inject 
additional resources in each and every ClassLoader implementation. JDK 
ClassLoader implementations could be made to "obey" the 
defineResource(), but this would not be a universal "fix" and code 
relying on defineResource() would only work in environments using JDK 
ClassLoader implementations.

Regards, Peter


From volker.simonis at gmail.com  Tue Aug 28 12:12:40 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 28 Aug 2018 14:12:40 +0200
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <AD719A3D-3C9D-46FD-B3D5-3DDE9B8A700A@oracle.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
 <CA+3eh1114qD9+vM2TymPeaLdAfSJ3YC_2umC2TQJ9OtTo+HeMw@mail.gmail.com>
 <AD719A3D-3C9D-46FD-B3D5-3DDE9B8A700A@oracle.com>
Message-ID: <CA+3eh1002mA1bQfqWtkWoyyBXQr2YoY7j=aBpubXQStC-HrXKA@mail.gmail.com>

On Tue, Aug 28, 2018 at 2:26 AM Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> Hi Volker,
>
> On Aug 27, 2018, at 6:53 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> sorry, I'm a little late in the game. I've just looked at your change
> and in general it looks good!
>
>
> Thanks: better late than never!
>
> There's one thing however I think you still have to fix. After
> changing 'stat64' to 'stat' in UnixFileSystem_md.c you should define
> 'stat' to 'stat64' on AIX if you don't want to change the current
> behavior:
>
> $ hg diff
> diff -r 8455a2fda5a8 src/java.base/unix/native/libjava/UnixFileSystem_md.c
> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
> Aug 27 11:30:50 2018 +0200
> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c     Mon
> Aug 27 14:55:07 2018 +0200
> @@ -59,6 +59,7 @@
>   #define opendir opendir64
>   #define readdir readdir64
>   #define closedir closedir64
> +  #define stat stat64
> #endif
>
> #if defined(__solaris__) && !defined(NAME_MAX)
>
>
> Thanks for pointing that out. An updated webrev with this change is at
>
> http://cr.openjdk.java.net/~bpb/8207744/webrev.05/
>
> The build and first tests with this addition look good. I'll also put
> the fix into our nightly queue to run some more extensive tests and
> let you know the results tomorrow.
>
>
> I ran this revision through our test system and there were no failures on the platforms we usually test. If your tests succeed then this should be good to go unless there are objections.
>

Our internal testing was successful as well.

Ready to push!

Regards,
Volker


> Thanks,
>
> Brian

From andrew_m_leonard at uk.ibm.com  Tue Aug 28 14:18:37 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Tue, 28 Aug 2018 15:18:37 +0100
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
Message-ID: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>

Hi,
We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's 
default compiler options has highlighted a couple of native code issues, 
with undefined behaviours:
  - validating loop test array bounds 
  - left shifts of negative values 
I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
and attached the webrev fix here: 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 

This has already been discussed and refined on the "s390x-port-dev" 
maillist
and as it was pointed out, it should have been posted here...

I'd like to request a sponsor for this fix please?

Many thanks
Andrew


Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From brian.burkhalter at oracle.com  Tue Aug 28 14:52:43 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 28 Aug 2018 07:52:43 -0700
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
Message-ID: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>

Hi Andrew,

It was suggested that it would be preferable to dial down the compilation settings for the fdlibm code rather than make a source code change. Was this investigated?

Thanks,

Brian

On Aug 28, 2018, at 7:18 AM, Andrew Leonard <andrew_m_leonard at uk.ibm.com> wrote:

> We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's 
> default compiler options has highlighted a couple of native code issues, 
> with undefined behaviours:
>  - validating loop test array bounds 
>  - left shifts of negative values 
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here: 
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
> 
> This has already been discussed and refined on the "s390x-port-dev" 
> maillist
> and as it was pointed out, it should have been posted here...
> 
> I'd like to request a sponsor for this fix please?


From li.jiang at oracle.com  Tue Aug 28 14:56:09 2018
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Tue, 28 Aug 2018 22:56:09 +0800
Subject: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
Message-ID: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>

Hi,

Please review the changes for ISO 4217 Amendment #168 #169.

Bugs:
https://bugs.openjdk.java.net/browse/JDK-8208746   168
https://bugs.openjdk.java.net/browse/JDK-8209775   169

Only in amendment #168 has real currency data update for Java, but I 
also updated the data version to #169 for consistent.


Changes include:

  - Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 928 
minor 2
  - Update the currency name to 'Bol?var Soberano'
  - Move the currency VEF to historical currencies
  - Correct the currency name for PHILIPPINES (THE): Philippine Peso 
(instead of Piso)
  - Change the country name: SWAZILAND to ESWATINI

Webrev:
http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/

Build and test passed on mach5 for all platforms.

Thanks,
Leo




From brian.burkhalter at oracle.com  Tue Aug 28 16:18:26 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 28 Aug 2018 09:18:26 -0700
Subject: [12] (AIX) 8207744: Clean up inconsistent use of opendir/closedir
 versus opendir64/closedir64
In-Reply-To: <CA+3eh1002mA1bQfqWtkWoyyBXQr2YoY7j=aBpubXQStC-HrXKA@mail.gmail.com>
References: <e1664103eebb46a68771cc90b91b1366@sap.com>
 <95EFD922-BA48-4ECC-B0E2-9E16558C3CE1@oracle.com>
 <e5af840807654031ab854b2fbc6714aa@sap.com>
 <2FB77D46-C1AA-432C-9F37-A0B7EA10DC8B@oracle.com>
 <303a1a86a8db4011be0717f7bd9aa8d2@sap.com>
 <E37B996D-38D6-4818-91E6-B01E3A0F8BFE@oracle.com>
 <da9951b8d7c04210a46a12b0ba43b16d@sap.com>
 <003DBE66-1A74-47B8-B169-A45705F06644@oracle.com>
 <12592E84-7473-4CCB-806E-AB8F48C2C199@oracle.com>
 <CAEgw74CmUW4Qy6Ehha=W_b8mFhBUe3TCZVu4oVmi+ok-1_ebRA@mail.gmail.com>
 <769009B0-E6C7-497B-A7FB-ABDBD5A444D1@oracle.com>
 <CAEgw74DsU3ffk1LNMatQ_T2hfsp8+W4nLUKfQr1gFUKA0ctH7w@mail.gmail.com>
 <45B266C5-C4B7-473D-A04F-6CC808903E98@oracle.com>
 <5A487D6E-CF5D-4190-AD1C-8D9E9BF71F0F@oracle.com>
 <CA+3eh1114qD9+vM2TymPeaLdAfSJ3YC_2umC2TQJ9OtTo+HeMw@mail.gmail.com>
 <AD719A3D-3C9D-46FD-B3D5-3DDE9B8A700A@oracle.com>
 <CA+3eh1002mA1bQfqWtkWoyyBXQr2YoY7j=aBpubXQStC-HrXKA@mail.gmail.com>
Message-ID: <DD034B24-9A0E-4EE9-A2C3-1192EA5209F2@oracle.com>

Hi Volker,

Thanks for the corroboration. I?ll plan to push this tomorrow.

Brian

On Aug 28, 2018, at 5:12 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> Our internal testing was successful as well.
> 
> Ready to push!


From erik.joelsson at oracle.com  Tue Aug 28 16:20:31 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 28 Aug 2018 09:20:31 -0700
Subject: RFR 8209064: Make intellij support more robust after changes for
 2018.2
In-Reply-To: <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com>
References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com>
 <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com>
 <f5543acc-22ba-1f01-2ff1-4ab5f2502038@oracle.com>
 <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com>
Message-ID: <d6b04a98-9fec-87b4-7728-b0feafca3c40@oracle.com>

Looks ok to me.

/Erik


On 2018-08-27 07:07, Maurizio Cimadamore wrote:
> As I was about to push this, I realize there was a minor nit with the 
> way in which build.xml files found some classes inside the generated 
> .idea folder - that is, the path to this folder was defined in a 
> relative way from the location of the script file.
>
> A more robust way to get there is to setup an idea.dir ant variable 
> which is dynamically populated by the IDE with the known location of 
> the project IML file.
>
> The only files touched were the two project build.xml files, as well 
> as the idea ant.xml files.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8209064_v2
>
> Maurizio
>
>
> On 23/08/18 14:21, Maurizio Cimadamore wrote:
>>
>>
>> On 21/08/18 10:31, Magnus Ihse Bursie wrote:
>>> Hi Maurizio!
>>>
>>> Even if this only incidentally relates to the build, please always 
>>> include build-dev when making changes in the "make" directory.
>> I will - thanks
>>>
>>> As far as I can understand, your changes looks good. One question: 
>>> the build.xml was previously stored as a "template", and copied to 
>>> the output directory. Now it's left in the source tree. I assume 
>>> that there was no actual transformations or changes made to the 
>>> template before? So that the scripts do not modify the source tree 
>>> version, that is.
>> You are correct - the script is not meant to be modified; customized 
>> properties are injected by the runtime environment - such properties 
>> are defined in the ant.xml file and that is indeed a template file 
>> (so it can be customized).
>>
>> Thanks
>> Maurizio
>>>
>>> /Magnus
>>>
>>> On 2018-08-07 13:21, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> last week I submitted an 'emergency' patch to fix intellij project 
>>>> support after 2018.2 changes. The goal of these changes was to move 
>>>> the build.xml ant file out of the .idea folder, as the IDE no 
>>>> longer supported DOM indexing in such folders (as a result of 
>>>> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, 
>>>> I tweaked the scripts to copy build.xml in the build folder.
>>>>
>>>> Thinking more about this issue, there's a more robust fix possible, 
>>>> which doesn't involve moving files to the build folder (which could 
>>>> be potentially unreliable, depending on how people build the JDK). 
>>>> In fact, the best solution is to leave build.xml where it is, and 
>>>> fix the remaining configuration files to point at it. This allows 
>>>> to revert all changes in the scripts that set up the project 
>>>> configuration (bin/idea.sh for JDK, and make/langtools/build.xml 
>>>> for langtools).
>>>>
>>>> For the langtools project a bit more changes were necessary, given 
>>>> that in langtools we did not have a 'template' folder - and all 
>>>> intellij files were dumped onto the same path. So I had to move the 
>>>> configuration langtools files (all but build.xml) under a new 
>>>> template folder (located under make/langtools/intellij/make) and 
>>>> place build.xml outside it. Then tweak the build.xml script to work 
>>>> off this new template folder. These are all small conceptual 
>>>> changes, but the impact on the webrev is quite biggie (because of 
>>>> file renaming etc.).
>>>>
>>>> I also took the chance to fix some issues with the JDK project ANT 
>>>> configuration (see changes in make/idea/template/workspace.xml), as 
>>>> the last changes did not update the location of the ant file used 
>>>> here - as a result no ant target entries were showing up under the 
>>>> Build menu.
>>>>
>>>> Webrev here:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8209064/
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>


From scolebourne at joda.org  Tue Aug 28 16:38:47 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 28 Aug 2018 17:38:47 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
Message-ID: <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>

On 28 August 2018 at 08:17, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 28/08/2018 07:55, Peter Levart wrote:
> Right, and any class injected with Lookup.defineClass can be located with
> methods such as Class.forName or Lookup.findClass. There is no equivalent
> for resources, at least not without extending the ClassLoader API in ways
> that would work with existing implementations.

OK, so maybe we've established what could be done - a new method on
ClassLoader that would initially not work on implementations outside
the JDK.

So, there is a functionality gap here, but I'm guessing no particular
desire to make a change.

Stephen

From igor.ignatyev at oracle.com  Tue Aug 28 16:50:17 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 28 Aug 2018 09:50:17 -0700
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
Message-ID: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
> 698 lines changed: 114 ins; 240 del; 344 mod

Hi all,

could you please review this clean up of jdk testlibrary?
the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.

testing: changed tests + :jdk_desktop test group
webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8210039

Thanks,
-- Igor

From Alan.Bateman at oracle.com  Tue Aug 28 16:55:19 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Aug 2018 17:55:19 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
Message-ID: <eeab2349-62e2-51a1-15c4-c5ca58bdff33@oracle.com>

On 28/08/2018 17:38, Stephen Colebourne wrote:
> :
> OK, so maybe we've established what could be done - a new method on
> ClassLoader that would initially not work on implementations outside
> the JDK.
>
> So, there is a functionality gap here, but I'm guessing no particular
> desire to make a change.
>
I don't see this as a gap as there is no support for making new classes 
visible via the class path either.? As I think we've concluded, doing so 
would require extending the ClassLoader API and would require all custom 
implementations to support it.

-Alan

From naoto.sato at oracle.com  Tue Aug 28 17:09:34 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 28 Aug 2018 10:09:34 -0700
Subject: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
In-Reply-To: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>
References: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>
Message-ID: <d03793a5-c07c-bbc3-fd23-1e3b6b9181c1@oracle.com>

Hi Leo,

Looks good to me. Also, please work with sustaining wrt backports.

Naoto

On 8/28/18 7:56 AM, li.jiang at oracle.com wrote:
> Hi,
> 
> Please review the changes for ISO 4217 Amendment #168 #169.
> 
> Bugs:
> https://bugs.openjdk.java.net/browse/JDK-8208746?? 168
> https://bugs.openjdk.java.net/browse/JDK-8209775?? 169
> 
> Only in amendment #168 has real currency data update for Java, but I 
> also updated the data version to #169 for consistent.
> 
> 
> Changes include:
> 
>  ?- Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 928 
> minor 2
>  ?- Update the currency name to 'Bol?var Soberano'
>  ?- Move the currency VEF to historical currencies
>  ?- Correct the currency name for PHILIPPINES (THE): Philippine Peso 
> (instead of Piso)
>  ?- Change the country name: SWAZILAND to ESWATINI
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/
> 
> Build and test passed on mach5 for all platforms.
> 
> Thanks,
> Leo
> 
> 
> 

From peter.levart at gmail.com  Tue Aug 28 19:43:48 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 28 Aug 2018 21:43:48 +0200
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
Message-ID: <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>



On 08/28/2018 06:38 PM, Stephen Colebourne wrote:
> On 28 August 2018 at 08:17, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 28/08/2018 07:55, Peter Levart wrote:
>> Right, and any class injected with Lookup.defineClass can be located with
>> methods such as Class.forName or Lookup.findClass. There is no equivalent
>> for resources, at least not without extending the ClassLoader API in ways
>> that would work with existing implementations.
> OK, so maybe we've established what could be done - a new method on
> ClassLoader that would initially not work on implementations outside
> the JDK.
>
> So, there is a functionality gap here, but I'm guessing no particular
> desire to make a change.
>
> Stephen

Stephen,

Do you think this functionality is really needed in programs? It seems 
useful just for testing. What you're asking is to make a kind of 
resource repository from ClassLoader. The next thing after 
defineResource() would be removeResource() or hideResource(), etc...

defineClass() doesn't really fall into that category. It doesn't expose 
the .class file resource. defineClass() is there for an entirely 
different purpose. Classes hold code which executes in the confines of 
the JVM security model governing access to class members, so there's no 
way to define a class that would have access to members of encapsulated 
classes of some module without defining it in the same module, which 
means that it has to be defined by the same class loader as encapsulated 
classes it wants to access.

Testing loading and interpretation of resources OTOH can be performed by 
staging a separate ClassLoader and handing it to tested code.

So is there a way to achieve what you want for your test with existing 
API? What does your tested method accept as input?

Regards, Peter


From scolebourne at joda.org  Tue Aug 28 21:21:24 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 28 Aug 2018 22:21:24 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
 <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>
Message-ID: <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>

On Tue, 28 Aug 2018 at 20:43, Peter Levart <peter.levart at gmail.com> wrote:
> Do you think this functionality is really needed in programs? It seems useful just for testing.

Why do people add classes at runtime? Might they not reasonably want
to also add resources for those classes?

The key point here is that this all worked before Java 9 modules. But
since resources are now encapsulated, adding a new ClassLoader is no
longer sufficient to inject a resource, as it doesn't get the right
module encapsulation that way. My experience more generally has been
that encapsulating resources in Java 9 modules has broken key
assumptions in almost every library I maintain. Remember that library
maintainers now have to to develop and test code like this for three
different environments, Java 8, Java 9 classpath and Java 9 modulepath
- its very painful.

> So is there a way to achieve what you want for your test with existing API?

Probably. I could have a separate maven module creating a separate
modular jar file with the testing resource in it, and run the test
using both the classpath mode and modulepath. I'm not going to be
doing that as the benefits are too low compared to the cost.

Stephen

From joe.darcy at oracle.com  Wed Aug 29 01:33:20 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 28 Aug 2018 18:33:20 -0700
Subject: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
In-Reply-To: <d03793a5-c07c-bbc3-fd23-1e3b6b9181c1@oracle.com>
References: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>
 <d03793a5-c07c-bbc3-fd23-1e3b6b9181c1@oracle.com>
Message-ID: <5d5267f7-357f-8039-568a-ecfd45cdd7ec@oracle.com>

Hello,

Should these changes have CSR requests?

Cheers,

-Joe


On 8/28/2018 10:09 AM, Naoto Sato wrote:
> Hi Leo,
>
> Looks good to me. Also, please work with sustaining wrt backports.
>
> Naoto
>
> On 8/28/18 7:56 AM, li.jiang at oracle.com wrote:
>> Hi,
>>
>> Please review the changes for ISO 4217 Amendment #168 #169.
>>
>> Bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8208746?? 168
>> https://bugs.openjdk.java.net/browse/JDK-8209775?? 169
>>
>> Only in amendment #168 has real currency data update for Java, but I 
>> also updated the data version to #169 for consistent.
>>
>>
>> Changes include:
>>
>> ??- Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 
>> 928 minor 2
>> ??- Update the currency name to 'Bol?var Soberano'
>> ??- Move the currency VEF to historical currencies
>> ??- Correct the currency name for PHILIPPINES (THE): Philippine Peso 
>> (instead of Piso)
>> ??- Change the country name: SWAZILAND to ESWATINI
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/
>>
>> Build and test passed on mach5 for all platforms.
>>
>> Thanks,
>> Leo
>>
>>
>>


From naoto.sato at oracle.com  Wed Aug 29 01:44:39 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 28 Aug 2018 18:44:39 -0700
Subject: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
In-Reply-To: <5d5267f7-357f-8039-568a-ecfd45cdd7ec@oracle.com>
References: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>
 <d03793a5-c07c-bbc3-fd23-1e3b6b9181c1@oracle.com>
 <5d5267f7-357f-8039-568a-ecfd45cdd7ec@oracle.com>
Message-ID: <e1109981-8db6-1e11-c716-a2194286f065@oracle.com>

Hi Joe,

This is a typical currency data change, and does not involve any public 
interface changes, so I think CSR is not needed. We haven't filed CSRs 
for such changes in the past.

Naoto

On 8/28/18 6:33 PM, joe darcy wrote:
> Hello,
> 
> Should these changes have CSR requests?
> 
> Cheers,
> 
> -Joe
> 
> 
> On 8/28/2018 10:09 AM, Naoto Sato wrote:
>> Hi Leo,
>>
>> Looks good to me. Also, please work with sustaining wrt backports.
>>
>> Naoto
>>
>> On 8/28/18 7:56 AM, li.jiang at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the changes for ISO 4217 Amendment #168 #169.
>>>
>>> Bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8208746?? 168
>>> https://bugs.openjdk.java.net/browse/JDK-8209775?? 169
>>>
>>> Only in amendment #168 has real currency data update for Java, but I 
>>> also updated the data version to #169 for consistent.
>>>
>>>
>>> Changes include:
>>>
>>> ??- Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 
>>> 928 minor 2
>>> ??- Update the currency name to 'Bol?var Soberano'
>>> ??- Move the currency VEF to historical currencies
>>> ??- Correct the currency name for PHILIPPINES (THE): Philippine Peso 
>>> (instead of Piso)
>>> ??- Change the country name: SWAZILAND to ESWATINI
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/
>>>
>>> Build and test passed on mach5 for all platforms.
>>>
>>> Thanks,
>>> Leo
>>>
>>>
>>>
> 

From xueming.shen at oracle.com  Wed Aug 29 02:09:42 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 28 Aug 2018 19:09:42 -0700
Subject: RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly while
 processing JAR file with "/" as a directory inside.
Message-ID: <5B860066.3050201@oracle.com>

Hi,

Please help review the proposed change for JDK-8197398.

issue: https://bugs.openjdk.java.net/browse/JDK-8197398
webrev: http://cr.openjdk.java.net/~sherman/8197398/webrev

A little background:

The existing zipfs has an assumption that the "normal/healthy/secured" 
zip/jar file should not
include any entry that has an absolute path, root "/" included. Various 
jar/zip tools have been
fixed/patched in the past years to avoid create such a jar/zip file for 
security reason. But there
are zip/jar files in the wild that do include absolute paths and do 
include a "/" root sometime, the
offending jar file included in the bug report is just one of those.

With this "wrong" assumption, the existing zipfs implementation always 
add a pseudo root
directory before building the internal inode tree and unfortunately 
attaches the "real" root
entry (exists in the jar/zip file) to be its child, in which trigger a 
circle when iteration.

The proposed change is to solve this problem by only adding the pseudo 
root when there is no
real root in the zip/jar file. Further the proposed change will try to 
"normalize" the zip/jar file
when it has any update needs to sync/write the update to the underlying 
zip/jar file when
closing, by removing any absolute path for all the entries, root "/" 
included, with the assumption
that the zipfis implementation should never create/generate an unsecured 
zip/jar file.


Thanks,
Sherman




From mearvk at outlook.com  Wed Aug 29 03:05:59 2018
From: mearvk at outlook.com (mr rupplin)
Date: Wed, 29 Aug 2018 03:05:59 +0000
Subject: Java VM Questions
Message-ID: <SN6PR07MB5022D7AC7390F39B05C7124CDA090@SN6PR07MB5022.namprd07.prod.outlook.com>

Can I ask you guys a quick question.  Does the VM development team plan on implementing any pure pass by reference.  Also I think we would like security and RMI integration going forward with the VM directly.  No way to hook memory allocation seems like a miss.

Let me know with some feedback.

Thanks.

Max R.

Get Outlook for Android<https://aka.ms/ghei36>


From jai.forums2013 at gmail.com  Wed Aug 29 04:36:42 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 29 Aug 2018 10:06:42 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
Message-ID: <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>

Anyone willing to help review the patch, please?

-Jaikiran


On 20/08/18 5:56 PM, Jaikiran Pai wrote:
> Hello everyone,
>
> I'm requesting a review of a documentation change which was discussed in
> a recent thread[1][2]. Here's an initial proposed draft, for a better
> documentation of Arrays.asList method:
>
> ??? /**
> ???? * Returns a fixed-size list backed by the specified array. The passed
> ???? * array is held as a reference in the returned list. Any subsequent
> ???? * changes made to the array contents will be visible in the returned
> ???? * list. Similarly any changes that happen in the returned list will
> ???? * also be visible in the array. The returned list is serializable and
> ???? * implements {@link RandomAccess}.
> ???? *
> ???? * <p>The returned list can be changed only in certain ways. Operations
> ???? * like {@code add}, {@code remove}, {@code clear} and other such, that
> ???? * change the size of the list aren't allowed. Operations like
> ???? * {@code replaceAll}, {@code set}, that change the elements in the list
> ???? * are permitted.
> ???? *
> ???? * <p>This method acts as bridge between array-based and
> collection-based
> ???? * APIs, in combination with {@link Collection#toArray}.
> ???? *
> ???? * @apiNote
> ???? * This method also provides a convenient way to create a fixed-size
> ???? * list initialized to contain several elements:
> ???? * <pre>
> ???? *???? List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe",
> "Curly");
> ???? * </pre>
> ???? *
> ???? * <p>The returned list throws a {@link
> UnsupportedOperationException} for
> ???? * operations that aren't permitted. Certain implementations of the
> returned
> ???? * list might choose to throw the exception only if the call to such
> methods
> ???? * results in an actual change, whereas certain other
> implementations may
> ???? * always throw the exception when such methods are called.
> ???? *
> ???? * @param <T> the class of the objects in the array
> ???? * @param a the array by which the list will be backed
> ???? * @return a list view of the specified array
> ???? */
> ??? @SafeVarargs
> ??? @SuppressWarnings("varargs")
> ??? public static <T> List<T> asList(T... a)
>
>
> I've edited some of the existing documentation of that method, moved
> some existing parts into @apiNote and added additional parts both to the
> spec as well as the @apiNote. For a complete reference of what's
> changed, I've also attached a patch of this change.
>
> P.S: Is there a specific (make) target that I can run to make sure
> changes like this one haven't caused any javadoc generation issues? I
> typically run just "make" and did it this time too, but I'm not sure it
> parses and generates the javadocs (couldn't find it in the generated
> exploded build image).
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
>
> [2] https://bugs.openjdk.java.net/browse/JDK-7033681
>
> -Jaikiran


From Alan.Bateman at oracle.com  Wed Aug 29 06:53:39 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Aug 2018 07:53:39 +0100
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
 <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>
 <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
Message-ID: <b0fb017f-02e7-ba9f-22c2-98834a67a4ab@oracle.com>

On 28/08/2018 22:21, Stephen Colebourne wrote:
> :
> The key point here is that this all worked before Java 9 modules. But
> since resources are now encapsulated, adding a new ClassLoader is no
> longer sufficient to inject a resource, as it doesn't get the right
> module encapsulation that way.
The article you cited relied on two hacks and was very fragile (run the 
example with JDK 8 and -Djava.system.classloader set on the command line 
and you'll see how it breaks with older JDK releases too).

In general, and aside from special support for agents, the JDK has never 
had a supported mechanism for dynamically extending the class path. The 
right way to do this type of thing is to create your own ClassLoader 
that you specify to Class.forName to load classes or invoke its 
getResource to locate resources that you want to make available.


>   My experience more generally has been
> that encapsulating resources in Java 9 modules has broken key
> assumptions in almost every library I maintain.
Existing libraries should work on the class path as before. The only two 
cases where you may have issues with existing deployments are:

1. Code that invokes getResourceXXX on a Class in a named module on the 
assumption that the resource to be found on the class path. This one has 
come up a few times, one of the examples discussed here was in Derby DB 
where it used Object.getResource(...) to locate a derby resource file. 
That one is easily fixed to invoke getResource on one of the classes in 
the same JAR file as the resource.

2. Code uses getResourceXXX methods to locate JDK internal (non-class) 
resources. This hasn't come up very often.

This is of course documented in the JDK 9 release notes.

> Remember that library
> maintainers now have to to develop and test code like this for three
> different environments, Java 8, Java 9 classpath and Java 9 modulepath
> - its very painful.
If a library maintainer migrates a library to an explicit module (I 
really mean "explicit" here, as in writing a module-info.java) then they 
will need to take resource encapsulation into account.

-Alan.

From peter.levart at gmail.com  Wed Aug 29 09:37:46 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 29 Aug 2018 11:37:46 +0200
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
 <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>
 <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
Message-ID: <fa0493ec-1c1f-6840-353f-ec52f3e26ee4@gmail.com>

Hi Stephen,

On 08/28/2018 11:21 PM, Stephen Colebourne wrote:
> On Tue, 28 Aug 2018 at 20:43, Peter Levart <peter.levart at gmail.com> wrote:
>> Do you think this functionality is really needed in programs? It seems useful just for testing.
> Why do people add classes at runtime? Might they not reasonably want
> to also add resources for those classes?
>
> The key point here is that this all worked before Java 9 modules. But
> since resources are now encapsulated, adding a new ClassLoader is no
> longer sufficient to inject a resource, as it doesn't get the right
> module encapsulation that way.

This all worked before Java 9 module by adding a new ClassLoader only if 
all of the following was true:

- you added a new ClassLoader that resolved a resource
- you passed the instance of that loader to the library method
- the library method used this loader instance to resolve the resource

I claim that this still works in Java 9 regardless of whether the 
library method is located in a module or not.

Before Java 9 modules you couldn't just magically "inject" a resource by 
adding new ClassLoader if the library code used Class.getResource() with 
a Class instance of some class residing in the library itself. For this 
to work, the library class would also have to be loaded by this new 
ClassLoader or by a child of this new ClassLoader. The assumption that 
the library is loaded by the same (or even child of) class loader that 
also resolves the resources of user artifacts is easily broken even 
before Java 9 modules. Imagine deploying user artifacts as a plug-in in 
some container while the library is in the parent "container" class-loader.

>   My experience more generally has been
> that encapsulating resources in Java 9 modules has broken key
> assumptions in almost every library I maintain.

Every module decides by itself whether it wants to encapsulate resources 
or not. If some resources of some module are meant to be resolved by a 
library, they will not be encapsulated and your assumptions (of 
non-encapsulation) will still hold. The encapsulation is not a problem. 
The problem is the assumption that the library and user artifacts are 
always collocated (in the same class loader before JDK 9 or in the same 
module post JDK 9). The correct library API that resolves user artifact 
resources is always such that takes as a parameter either ClassLoader or 
Class of the user artifact. And this should still work even if user 
artifact is a module and/or if library is a module, providing that 
resources are not encapsulated in case of user artifact being a module.

>   Remember that library
> maintainers now have to to develop and test code like this for three
> different environments, Java 8, Java 9 classpath and Java 9 modulepath
> - its very painful.

I think that by testing artifact being a Java 9 module and being on Java 
9 class path is enough. If it works in the later case it should also 
work in Java 8. At least as far as resolving resources is the concern.

>> So is there a way to achieve what you want for your test with existing API?
> Probably. I could have a separate maven module creating a separate
> modular jar file with the testing resource in it, and run the test
> using both the classpath mode and modulepath. I'm not going to be
> doing that as the benefits are too low compared to the cost.

Compared to that, what would be the testing setup if you had a 
.defineResource() method?

Regards, Peter


From Alan.Bateman at oracle.com  Wed Aug 29 10:22:46 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Aug 2018 11:22:46 +0100
Subject: RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly
 while processing JAR file with "/" as a directory inside.
In-Reply-To: <5B860066.3050201@oracle.com>
References: <5B860066.3050201@oracle.com>
Message-ID: <347effc7-149f-fcf7-77b3-59ad572634b0@oracle.com>

On 29/08/2018 03:09, Xueming Shen wrote:
> Hi,
>
> Please help review the proposed change for JDK-8197398.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8197398
> webrev: http://cr.openjdk.java.net/~sherman/8197398/webrev
>
> A little background:
>
> The existing zipfs has an assumption that the "normal/healthy/secured" 
> zip/jar file should not
> include any entry that has an absolute path, root "/" included. 
> Various jar/zip tools have been
> fixed/patched in the past years to avoid create such a jar/zip file 
> for security reason. But there
> are zip/jar files in the wild that do include absolute paths and do 
> include a "/" root sometime, the
> offending jar file included in the bug report is just one of those.
The approach looks okay, I think just wonder if the test could be 
expanded to cover entry with repeated leading slashes.

One nit is that hasAbsolutePath (and also the existing readOnly) aren't 
final. One suggestion is for initCEN to return a CEN object that defines 
array() and hasAbsolutePath() methods that you can use in the 
constructor for the initializing the final fields.

-Alan

From ecki at zusammenkunft.net  Wed Aug 29 10:56:36 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 29 Aug 2018 10:56:36 +0000
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>,
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
Message-ID: <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>

Hello,

Not an Reviewer But just wanted to give a short Feedback: I like the new Version it is really helpful.

However I wonder if the usage example should be outside of the apinote.

Given the existence of List.of() I wonder if you either mention it as a alternative to the example (with slightly different semantic) or just remove the sample completely?

?Similiar to List.of() which constructs an unmodifiable List from given elements Arrays.asList() can be used to construct a List from a fixed size of Elements. Both constructs won?t allow structural changes to the resulting List, however when constructed with asList() the content could be modified.?

But I must honestly say this would encourage a usage which is a bit questionable in many cases?

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: -997621984m Auftrag von
Gesendet: Mittwoch, August 29, 2018 9:07 AM
An: core-libs-dev at openjdk.java.net
Betreff: Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

Anyone willing to help review the patch, please?

-Jaikiran


On 20/08/18 5:56 PM, Jaikiran Pai wrote:
> Hello everyone,
>
> I'm requesting a review of a documentation change which was discussed in
> a recent thread[1][2]. Here's an initial proposed draft, for a better
> documentation of Arrays.asList method:
>
>     /**
>      * Returns a fixed-size list backed by the specified array. The passed
>      * array is held as a reference in the returned list. Any subsequent
>      * changes made to the array contents will be visible in the returned
>      * list. Similarly any changes that happen in the returned list will
>      * also be visible in the array. The returned list is serializable and
>      * implements {@link RandomAccess}.
>      *
>      * <p>The returned list can be changed only in certain ways. Operations
>      * like {@code add}, {@code remove}, {@code clear} and other such, that
>      * change the size of the list aren't allowed. Operations like
>      * {@code replaceAll}, {@code set}, that change the elements in the list
>      * are permitted.
>      *
>      * <p>This method acts as bridge between array-based and
> collection-based
>      * APIs, in combination with {@link Collection#toArray}.
>      *
>      * @apiNote
>      * This method also provides a convenient way to create a fixed-size
>      * list initialized to contain several elements:
>      * <pre>
>      *     List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe",
> "Curly");
>      * </pre>
>      *
>      * <p>The returned list throws a {@link
> UnsupportedOperationException} for
>      * operations that aren't permitted. Certain implementations of the
> returned
>      * list might choose to throw the exception only if the call to such
> methods
>      * results in an actual change, whereas certain other
> implementations may
>      * always throw the exception when such methods are called.
>      *
>      * @param <T> the class of the objects in the array
>      * @param a the array by which the list will be backed
>      * @return a list view of the specified array
>      */
>     @SafeVarargs
>     @SuppressWarnings("varargs")
>     public static <T> List<T> asList(T... a)
>
>
> I've edited some of the existing documentation of that method, moved
> some existing parts into @apiNote and added additional parts both to the
> spec as well as the @apiNote. For a complete reference of what's
> changed, I've also attached a patch of this change.
>
> P.S: Is there a specific (make) target that I can run to make sure
> changes like this one haven't caused any javadoc generation issues? I
> typically run just "make" and did it this time too, but I'm not sure it
> parses and generates the javadocs (couldn't find it in the generated
> exploded build image).
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
>
> [2] https://bugs.openjdk.java.net/browse/JDK-7033681
>
> -Jaikiran


From james.laskey at oracle.com  Wed Aug 29 14:00:31 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 29 Aug 2018 11:00:31 -0300
Subject: RFR - JDK-8200434 - String::align, String::indent (code review)
Message-ID: <866B7282-D7B1-4B63-9497-B43D7D84AC6C@oracle.com>

Please review the code  for  String::align and String::indent at the link below.

Notes:
	Includes a private version of String::isMultiline() which may be made into a public method at some future date
	Includes minor correctness clean up of StringLatin1.java, StringUTF16.java

webrev: http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8200434

Cheers,

? Jim


From matthias.baesken at sap.com  Wed Aug 29 14:01:56 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 29 Aug 2018 14:01:56 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
Message-ID: <b197f112ef474462aa4fc6773676a636@sap.com>

Hi Max, thanks for your input .

I created another webrev , this contains now   the suggested  SecurityProperties   class :

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/

Best regards, Matthias




> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Montag, 27. August 2018 17:35
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> 
> 
> > On Aug 27, 2018, at 10:25 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hi Alan ,
> >
> >> Will sun.net.util.SocketExceptions be changed to use the supporting
> >> class or is that a separate issue?
> >>
> >
> > I think this is a separate issue .
> >
> >> In terms of approach then I think what you have is okay although I think
> >> we should try to find a better name than "SecuritySystemPropertyHelper"
> >> and also get feedback from security-dev on whether they would prefer it
> >> in the sun.security tree with the other classes security classes.
> >
> > Suggestions are welcome , I  was a bit unsure about the name as well ?? !
> 
> I am OK with creating a sun.security.util.SecurityProperties class, and a
> method called privilegeGetOverridable() for the 1st part of
> SecuritySystemPropertyHelper::initTextProperty (by overridable I mean a
> system property can shadow the security property). I have no idea where
> the 2nd part should go. Maybe you can just create an
> includedInExceptions(String refName) method for this purpose.
> 
> So it will be something like this
> 
> public class SecurityProperties {
> 
>     public static String privilegeGetOverridable(String propName) {
>         return AccessController.doPrivileged((PrivilegedAction<String>)
>                 () -> {
>                     String val = System.getProperty(propName);
>                     if (val == null) {
>                         return Security.getProperty(propName);
>                     } else {
>                         return val;
>                     }
>                 });
>     }
> 
>     public static boolean includedInExceptions(String refName) {
>         String val = privilegeGetOverridable("jdk.includeInExceptions");
>         if (val == null){
>             return false;
>         }
>         String[] tokens = val.split(",");
>         for (String token : tokens) {
>             if (token.equalsIgnoreCase(refName))
>                 return true;
>         }
>         return false;
>     }
> }
> 
> Thanks
> Max
> 
> 
> >
> > Thanks, Matthias
> >
> >
> >> -----Original Message-----
> >> From: Alan Bateman <Alan.Bateman at oracle.com>
> >> Sent: Montag, 27. August 2018 15:52
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; Sean Mullan
> >> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>
> >> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
> >> dev at openjdk.java.net>
> >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> >> parsing of jar archives
> >>
> >> On 24/08/2018 15:52, Baesken, Matthias wrote:
> >>> Hello, I created another webrev :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
> >>>
> >>> - use now  jarPath  instead of  jarpath  in the java security file
> >>> -  moved the parsing of the property  to a more general location
> (separate
> >> class jdk/internal/util/SecuritySystemPropertyHelper.java  )
> >>> -  read now  from the InputStream and check for error conditions
> *before*
> >> setting jarFilename    in the Manifest  constructor
> >>>
> >> Will sun.net.util.SocketExceptions be changed to use the supporting
> >> class or is that a separate issue?
> >>
> >> In terms of approach then I think what you have is okay although I think
> >> we should try to find a better name than "SecuritySystemPropertyHelper"
> >> and also get feedback from security-dev on whether they would prefer it
> >> in the sun.security tree with the other classes security classes.
> >>
> >> -Alan


From weijun.wang at oracle.com  Wed Aug 29 14:27:23 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 29 Aug 2018 22:27:23 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <b197f112ef474462aa4fc6773676a636@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
Message-ID: <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>

SecurityProperties.java:

- Please add the copyright+license header to the new file.

- The "jdk.includeInExceptions" definition says there can be "Leading and trailing whitespaces". You might need to call trim() on each token.

java.security:

- I would suggest saying "classes from the java.util.jar package" or just "when parsing a jar file".

Others:

- What will the output look like? Is it "/tmp/x.jar:100"? If I read correctly, the line number is of the manifest and not the jar file.

Thanks
Max

> On Aug 29, 2018, at 10:01 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Max, thanks for your input .
> 
> I created another webrev , this contains now   the suggested  SecurityProperties   class :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/
> 
> Best regards, Matthias
> 
> 
> 
> 
>> -----Original Message-----
>> From: Weijun Wang <weijun.wang at oracle.com>
>> Sent: Montag, 27. August 2018 17:35
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>> 
>> 
>> 
>>> On Aug 27, 2018, at 10:25 PM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> Hi Alan ,
>>> 
>>>> Will sun.net.util.SocketExceptions be changed to use the supporting
>>>> class or is that a separate issue?
>>>> 
>>> 
>>> I think this is a separate issue .
>>> 
>>>> In terms of approach then I think what you have is okay although I think
>>>> we should try to find a better name than "SecuritySystemPropertyHelper"
>>>> and also get feedback from security-dev on whether they would prefer it
>>>> in the sun.security tree with the other classes security classes.
>>> 
>>> Suggestions are welcome , I  was a bit unsure about the name as well ?? !
>> 
>> I am OK with creating a sun.security.util.SecurityProperties class, and a
>> method called privilegeGetOverridable() for the 1st part of
>> SecuritySystemPropertyHelper::initTextProperty (by overridable I mean a
>> system property can shadow the security property). I have no idea where
>> the 2nd part should go. Maybe you can just create an
>> includedInExceptions(String refName) method for this purpose.
>> 
>> So it will be something like this
>> 
>> public class SecurityProperties {
>> 
>>   public static String privilegeGetOverridable(String propName) {
>>       return AccessController.doPrivileged((PrivilegedAction<String>)
>>               () -> {
>>                   String val = System.getProperty(propName);
>>                   if (val == null) {
>>                       return Security.getProperty(propName);
>>                   } else {
>>                       return val;
>>                   }
>>               });
>>   }
>> 
>>   public static boolean includedInExceptions(String refName) {
>>       String val = privilegeGetOverridable("jdk.includeInExceptions");
>>       if (val == null){
>>           return false;
>>       }
>>       String[] tokens = val.split(",");
>>       for (String token : tokens) {
>>           if (token.equalsIgnoreCase(refName))
>>               return true;
>>       }
>>       return false;
>>   }
>> }
>> 
>> Thanks
>> Max
>> 
>> 
>>> 
>>> Thanks, Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alan Bateman <Alan.Bateman at oracle.com>
>>>> Sent: Montag, 27. August 2018 15:52
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Sean Mullan
>>>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>
>>>> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
>>>> dev at openjdk.java.net>
>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>>>> parsing of jar archives
>>>> 
>>>> On 24/08/2018 15:52, Baesken, Matthias wrote:
>>>>> Hello, I created another webrev :
>>>>> 
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
>>>>> 
>>>>> - use now  jarPath  instead of  jarpath  in the java security file
>>>>> -  moved the parsing of the property  to a more general location
>> (separate
>>>> class jdk/internal/util/SecuritySystemPropertyHelper.java  )
>>>>> -  read now  from the InputStream and check for error conditions
>> *before*
>>>> setting jarFilename    in the Manifest  constructor
>>>>> 
>>>> Will sun.net.util.SocketExceptions be changed to use the supporting
>>>> class or is that a separate issue?
>>>> 
>>>> In terms of approach then I think what you have is okay although I think
>>>> we should try to find a better name than "SecuritySystemPropertyHelper"
>>>> and also get feedback from security-dev on whether they would prefer it
>>>> in the sun.security tree with the other classes security classes.
>>>> 
>>>> -Alan
> 


From peter.levart at gmail.com  Wed Aug 29 16:20:43 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 29 Aug 2018 18:20:43 +0200
Subject: MethodHandles.Lookup.defineResource?
In-Reply-To: <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
References: <CACzrW9AwmSdOZMQTHL2vUqvv6t95KCWYCWF7PAX5Wn=ugx9QcQ@mail.gmail.com>
 <91acd996-cde3-6131-6938-0958792ae087@oracle.com>
 <CACzrW9CALzE7LhtMGeUtdTTzHM7x94DQ=mX5Nnaai4kRR902_Q@mail.gmail.com>
 <2fd94523-2f68-26ba-1dfd-4ab66d6792ab@gmail.com>
 <f7e4d5e0-dc0c-aafa-4cac-37e549d0df19@oracle.com>
 <CACzrW9DtsTO5vXVYw50TLsbRqNwdP2J8SH2b9pVQRWw_wvm3Cg@mail.gmail.com>
 <3d311312-d729-edbe-f8ff-ec9f1fe3e4bf@gmail.com>
 <CACzrW9CGuwOaVPAXC4Yzza=ZVH62a39xqt==Rv93Z1D=Xb=O-A@mail.gmail.com>
Message-ID: <1fd41306-34cb-efbe-f426-e20012c88725@gmail.com>

Hi Stephen,

On 08/28/2018 11:21 PM, Stephen Colebourne wrote:
>> So is there a way to achieve what you want for your test with existing API?
> Probably. I could have a separate maven module creating a separate
> modular jar file with the testing resource in it, and run the test
> using both the classpath mode and modulepath. I'm not going to be
> doing that as the benefits are too low compared to the cost.

The cost is not that big if you for example create yourself a reusable 
utility. You don't need to create maven modules etc., just to have a 
named or unnamed module participating in your test.

Say you have the following library class you want to test (this should 
be equivalent to your ExampleMarketDataBuilder):

import java.io.IOException;
import java.io.InputStream;
import java.io.UncheckedIOException;
import java.net.URL;
import java.nio.charset.StandardCharsets;

public class ResUtil {

 ??? public static String readResource(ClassLoader classLoader, String 
resName) {
 ??????? URL url = classLoader.getResource(resName);
 ??????? return url == null ? null : readUrl(url);
 ??? }

 ??? public static String readResource(Class<?> clazz, String resName) {
 ??????? URL url = clazz.getResource(resName);
 ??????? return url == null ? null : readUrl(url);
 ??? }

 ??? private static String readUrl(URL url) {
 ??????? try (InputStream in = url.openStream()) {
 ??????????? byte[] bytes = in.readAllBytes();
 ??????????? return new String(bytes, StandardCharsets.UTF_8);
 ??????? } catch (IOException e) {
 ??????????? throw new UncheckedIOException(e);
 ??????? }
 ??? }
}


You can test it in both modes with the following test:

import lib.ResUtil;
import si.pele.layerbuilder.ModuleLayerBuilder;
import java.net.URLClassLoader;

public class ResTest {
 ??? public static void main(String[] args) throws Exception {

 ??????? ModuleLayerBuilder builder = new ModuleLayerBuilder();
 ??????? builder
 ??????????? .module("my.mod", mb -> mb
 ??????????????? .resource(
 ??????????????????? "module-info.java",
 ??????????????????? "module my.mod {",
 ??????????????????? "? opens my.pkg;",
 ??????????????????? "}"
 ??????????????? )
 ??????????????? .resource(
 ??????????????????? "my/pkg/Test.java",
 ??????????????????? "package my.pkg;",
 ??????????????????? "public class Test {",
 ??????????????????? "}"
 ??????????????? )
 ??????????????? .resource(
 ??????????????????? "my/pkg/readme.txt",
 ??????????????????? "HELLO WORLD!"
 ??????????????? )
 ??????????? );

 ??????? // test using "--class-path"

 ??????? try (URLClassLoader loader = builder.buildClassLoader()) {
 ??????????? Class<?> testClass = Class.forName("my.pkg.Test", false, 
loader);
 ??????????? System.out.println("Resolving in --class-path artifact via 
ClassLoader gives: " + ResUtil.readResource(loader, "my/pkg/readme.txt"));
 ??????????? System.out.println("Resolving in --class-path artifact via 
Class gives: " + ResUtil.readResource(testClass, "readme.txt"));
 ??????? }

 ??????? // test using "--module-path"

 ??????? {
 ??????????? ModuleLayer layer = builder.buildModuleLayer();
 ??????????? Module myMod = layer.findModule("my.mod").orElseThrow(() -> 
new RuntimeException("Can't find module: my.mod"));
 ??????????? ClassLoader loader = myMod.getClassLoader();
 ??????????? Class<?> testClass = Class.forName("my.pkg.Test", false, 
loader);
 ??????????? System.out.println("Resolving in --module-path artifact via 
ClassLoader gives: " + ResUtil.readResource(loader, "my/pkg/readme.txt"));
 ??????????? System.out.println("Resolving in --module-path artifact via 
Class gives: " + ResUtil.readResource(testClass, "readme.txt"));
 ??????? }
 ??? }
}


A ModuleLayerBuilder utility is not that complicated given all the 
API(s) that are available in JDK 9+. Here it is (you can adapt it to 
your needs if you want):

http://cr.openjdk.java.net/~plevart/misc/ModuleLayerBuilder/ModuleLayerBuilder.java


Regards, Peter


From Roger.Riggs at Oracle.com  Wed Aug 29 20:06:34 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Aug 2018 16:06:34 -0400
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes to
 the time-of-day clock
Message-ID: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>

Please review changes for:

8098798: Thread.join(ms) on Linux still affected by changes to the 
time-of-day clock
 ???? Use System.nanoTime to compute any remaining delay

8210004: Thread.sleep(millis, nanos) timeout returns early
 ???? Avoid an early return by rounding the milliseconds up if there are 
any nanoseconds as was done in Object.wait(ms, ns).

(If its not appropriate to do the two reviews together, I can split them).

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/

Thanks, Roger


From ivan.gerasimov at oracle.com  Wed Aug 29 21:18:19 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 29 Aug 2018 14:18:19 -0700
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
Message-ID: <ead26a55-0833-5a98-f417-20d227bfc978@oracle.com>

Hi Roger!

This is of course a corner case, but now if you call 
thread.join(Long.MAX_VALUE, 1) you'll get 
IllegalArgumentException("timeout value is negative");
And the same with sleep(long, int).

Before the fix, the same would happen with join(Long.MAX_VALUE, 500000), 
which was also not quite expected.

Would it make sense to do `if (nanos > 0 && millis < Long.MAX_VALUE)` 
just for extra accuracy?

With kind regards,
Ivan


On 8/29/18 1:06 PM, Roger Riggs wrote:
> Please review changes for:
>
> 8098798: Thread.join(ms) on Linux still affected by changes to the 
> time-of-day clock
>      Use System.nanoTime to compute any remaining delay
>
> 8210004: Thread.sleep(millis, nanos) timeout returns early
>      Avoid an early return by rounding the milliseconds up if there 
> are any nanoseconds as was done in Object.wait(ms, ns).
>
> (If its not appropriate to do the two reviews together, I can split 
> them).
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>
> Thanks, Roger
>
>

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Wed Aug 29 21:36:14 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Aug 2018 14:36:14 -0700
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
Message-ID: <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>

Thanks for taking this on.
Wait loops are notoriously hard to get right...

One sharp corner is that wait(0) waits forever, and TimeUnit conversion
truncates.  You can probably avoid those problems via TimeUnit.timedWait.

In code like this in j.u.c. we try to optimize away the call to nanoTime
when waiting is not necessary, by using a special "uninitialized" initial
value for remaining nanos, e.g. in FutureTask.awaitDone

        long startTime = 0L;    // Special value 0L means not yet parked

(I prefer the variable name "startTime")

(j.u.c. code can also be improved)

(there's a pre-existing buglet - we should probably check for overflow when
millis = MAX_VALUE and nanos > 0 (sigh))

(I would reorder clauses to first check the common case millis > 0, then
millis == 0, last the error case millis < 0)

(it's a bad API that millis < 0 is an error)


On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review changes for:
>
> 8098798: Thread.join(ms) on Linux still affected by changes to the
> time-of-day clock
>      Use System.nanoTime to compute any remaining delay
>
> 8210004: Thread.sleep(millis, nanos) timeout returns early
>      Avoid an early return by rounding the milliseconds up if there are
> any nanoseconds as was done in Object.wait(ms, ns).
>
> (If its not appropriate to do the two reviews together, I can split them).
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>
> Thanks, Roger
>
>

From ivan.gerasimov at oracle.com  Wed Aug 29 21:48:05 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 29 Aug 2018 14:48:05 -0700
Subject: RFR - JDK-8200434 - String::align, String::indent (code review)
In-Reply-To: <866B7282-D7B1-4B63-9497-B43D7D84AC6C@oracle.com>
References: <866B7282-D7B1-4B63-9497-B43D7D84AC6C@oracle.com>
Message-ID: <32e6536a-19bf-fafd-9eb8-6a5ff2fa35bb@oracle.com>

Hi Jim!

Why a new line is always added to the result of indent(int):

return stream.collect(Collectors.joining("\n", "", *"\n"*));

Because of this, a call to str.indent(0) depends on whether the string 
is single-line or multi-line: In the former case it is unchanged, while 
in the later case it gets a newline appended.
Moreover, if a multi-line string already ends with a new line, then a 
new new-line is not appended, which seems inconsistent.

I think, it may be better to always preserve the number of existing 
trailing new lines.

With kind regards,
Ivan


On 8/29/18 7:00 AM, Jim Laskey wrote:
> Please review the code  for  String::align and String::indent at the link below.
>
> Notes:
> 	Includes a private version of String::isMultiline() which may be made into a public method at some future date
> 	Includes minor correctness clean up of StringLatin1.java, StringUTF16.java
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8200434
>
> Cheers,
>
> ? Jim
>
>

-- 
With kind regards,
Ivan Gerasimov


From xueming.shen at oracle.com  Wed Aug 29 21:56:48 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Aug 2018 14:56:48 -0700
Subject: RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly
 while processing JAR file with "/" as a directory inside.
In-Reply-To: <347effc7-149f-fcf7-77b3-59ad572634b0@oracle.com>
References: <5B860066.3050201@oracle.com>
 <347effc7-149f-fcf7-77b3-59ad572634b0@oracle.com>
Message-ID: <5B8716A0.3000404@oracle.com>

On 8/29/18, 3:22 AM, Alan Bateman wrote:
> The approach looks okay, I think just wonder if the test could be 
> expanded to cover entry with repeated leading slashes.
>
> One nit is that hasAbsolutePath (and also the existing readOnly) 
> aren't final. One suggestion is for initCEN to return a CEN object 
> that defines array() and hasAbsolutePath() methods that you can use in 
> the constructor for the initializing the final fields.

It appears it's not necessary to have the "hasAbsolutePath" and pay the 
price to check in
initCEN(). I managed to do it locally inside copyLOCEntry(...).

http://cr.openjdk.java.net/~sherman/8197398/webrev/

Regarding "repeated leading slashes", I think you are opening another 
door for further
enhancement. We are not doing any real path normalization in 
ZipFileSystem for its existing
entry path, other than padding a "/" to make it like a normal path, 
mainly for better performance
when doing path lookup (while we do the normal normalization in ZipPath 
for String from external).
The zip spec basically does not specify anything regarding the canonical 
form of its entry
path normalization, exception "the entry is a dir if ends with a '/'. So 
it might be an
interesting RFE. the trade off is to have a more "complicated" logic 
somewhere during the
initialization.

Sherman

From Sergey.Bylokhov at oracle.com  Wed Aug 29 21:57:31 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 29 Aug 2018 14:57:31 -0700
Subject: <AWT Dev> RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
Message-ID: <eb1bc837-a821-4353-ec71-4d4828ba5b71@oracle.com>

Looks fine.

On 28/08/2018 09:50, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>> 698 lines changed: 114 ins; 240 del; 344 mod
> 
> Hi all,
> 
> could you please review this clean up of jdk testlibrary?
> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
> 
> testing: changed tests + :jdk_desktop test group
> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
> 
> Thanks,
> -- Igor
> 


-- 
Best regards, Sergey.

From li.jiang at oracle.com  Wed Aug 29 23:41:53 2018
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Thu, 30 Aug 2018 07:41:53 +0800
Subject: RFR: 8210153 : java/text/Format/NumberFormat/CurrencyFormat.java
 failed
Message-ID: <6542027f-4ca5-2a78-a13f-0c497aed4cc3@oracle.com>

Hi Naoto,

Please review the fix to update the currency symbol for VES.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8210153

Webrev:
http://cr.openjdk.java.net/~ljiang/8210153/webrev/

Built and tier1~tier3 tests passed on mach5.

Thanks,
Leo

From joe.darcy at oracle.com  Thu Aug 30 01:17:13 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 29 Aug 2018 18:17:13 -0700
Subject: RFR: 8208746 8209775 : ISO 4217 Amendment #168 #169 Update
In-Reply-To: <e1109981-8db6-1e11-c716-a2194286f065@oracle.com>
References: <067281cf-544a-aa87-b2e2-6c1b3030ed5a@oracle.com>
 <d03793a5-c07c-bbc3-fd23-1e3b6b9181c1@oracle.com>
 <5d5267f7-357f-8039-568a-ecfd45cdd7ec@oracle.com>
 <e1109981-8db6-1e11-c716-a2194286f065@oracle.com>
Message-ID: <5B874599.8080706@oracle.com>

Hi Naoto,

Thanks for checking; cheers,

-Joe

On 8/28/2018 6:44 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> This is a typical currency data change, and does not involve any 
> public interface changes, so I think CSR is not needed. We haven't 
> filed CSRs for such changes in the past.
>
> Naoto
>
> On 8/28/18 6:33 PM, joe darcy wrote:
>> Hello,
>>
>> Should these changes have CSR requests?
>>
>> Cheers,
>>
>> -Joe
>>
>>
>> On 8/28/2018 10:09 AM, Naoto Sato wrote:
>>> Hi Leo,
>>>
>>> Looks good to me. Also, please work with sustaining wrt backports.
>>>
>>> Naoto
>>>
>>> On 8/28/18 7:56 AM, li.jiang at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the changes for ISO 4217 Amendment #168 #169.
>>>>
>>>> Bugs:
>>>> https://bugs.openjdk.java.net/browse/JDK-8208746   168
>>>> https://bugs.openjdk.java.net/browse/JDK-8209775   169
>>>>
>>>> Only in amendment #168 has real currency data update for Java, but 
>>>> I also updated the data version to #169 for consistent.
>>>>
>>>>
>>>> Changes include:
>>>>
>>>>   - Update the currency for VENEZUELA (BOLIVARIAN REPUBLIC OF), VES 
>>>> 928 minor 2
>>>>   - Update the currency name to 'Bol?var Soberano'
>>>>   - Move the currency VEF to historical currencies
>>>>   - Correct the currency name for PHILIPPINES (THE): Philippine 
>>>> Peso (instead of Piso)
>>>>   - Change the country name: SWAZILAND to ESWATINI
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~ljiang/8208746/webrev.00/
>>>>
>>>> Build and test passed on mach5 for all platforms.
>>>>
>>>> Thanks,
>>>> Leo
>>>>
>>>>
>>>>
>>


From naoto.sato at oracle.com  Thu Aug 30 01:19:01 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 Aug 2018 18:19:01 -0700
Subject: RFR: 8210153 : java/text/Format/NumberFormat/CurrencyFormat.java
 failed
In-Reply-To: <6542027f-4ca5-2a78-a13f-0c497aed4cc3@oracle.com>
References: <6542027f-4ca5-2a78-a13f-0c497aed4cc3@oracle.com>
Message-ID: <6a320d3c-6389-14b4-869e-bb1da2f21b2b@oracle.com>

Please update the copyright year to "2018".  Otherwise looks good to me. 
No further review is needed.

Naoto

On 8/29/18 4:41 PM, li.jiang at oracle.com wrote:
> Hi Naoto,
> 
> Please review the fix to update the currency symbol for VES.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8210153
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/8210153/webrev/
> 
> Built and tier1~tier3 tests passed on mach5.
> 
> Thanks,
> Leo

From Alan.Bateman at oracle.com  Thu Aug 30 07:51:47 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Aug 2018 08:51:47 +0100
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
Message-ID: <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>



On 28/08/2018 17:50, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>> 698 lines changed: 114 ins; 240 del; 344 mod
> Hi all,
>
> could you please review this clean up of jdk testlibrary?
> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
>
> testing: changed tests + :jdk_desktop test group
> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
>
The updates to the Sockets policy file suggests using this 
jdk.test.lib.Platform/OSVersion requires permissions that the test 
infrastructure needs, not the test. It's not wrong but it's always a 
concern when tests running with a security manager are granted 
non-obvious permissions. I would be tempted to change this test to drop 
the usage of Platform/OSVersion so that the test can be granted only the 
permissions that it needs. Alternatively maybe we can just drop the OS 
check from this test if we can establish that there aren't test systems 
running Solaris 11.2 or older (the 11.3 update was 2015).

-Alan

From vyom.tewari at oracle.com  Thu Aug 30 09:06:20 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 30 Aug 2018 14:36:20 +0530
Subject: [12] RFR 8209773: Refactor shell test
 javax/naming/module/basic.sh to java
In-Reply-To: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
References: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
Message-ID: <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>

Hi Chris,

The refactored? java class (RunBasic.java) looks good to me.

Thanks,

Vyom


On Tuesday 28 August 2018 11:20 AM, Chris Yin wrote:
> Please have a review for below change to refactor shell test javax/naming/module/basic.sh to plain java, no test logic change, old shell script is removed at same time, thanks
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8209773
> webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/
>
> Regards,
> Chris


From chris.hegarty at oracle.com  Thu Aug 30 10:28:10 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 30 Aug 2018 11:28:10 +0100
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
Message-ID: <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>


> On 30 Aug 2018, at 08:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 28/08/2018 17:50, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>> 698 lines changed: 114 ins; 240 del; 344 mod
>> Hi all,
>> 
>> could you please review this clean up of jdk testlibrary?
>> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
>> 
>> testing: changed tests + :jdk_desktop test group
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
>> 
> The updates to the Sockets policy file suggests using this jdk.test.lib.Platform/OSVersion requires permissions that the test infrastructure needs, not the test. It's not wrong but it's always a concern when tests running with a security manager are granted non-obvious permissions.

The uses of test libraries with security manager is a little
cumbersome, and usually ends up with the test code being
granted more permissions than is necessary. I share Alan?s
concern.

Another alternative, that we used in other areas, is to grant
the test library only minimal permissions, separate to the
actual test code. For example:

http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24

-Chris.

From andrew_m_leonard at uk.ibm.com  Thu Aug 30 12:18:40 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Thu, 30 Aug 2018 13:18:40 +0100
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
Message-ID: <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>

Hi Brian,
Thanks for taking a look at this, I have just done a rebuild with a new 
patch with appropriate gcc disable warnings for these libraries:
http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 
This works fine, so if you think this is a more favourable approach for 
these libraries? i'd like to get this merged please.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 




From:   Brian Burkhalter <brian.burkhalter at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   28/08/2018 15:52
Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux



Hi Andrew,

It was suggested that it would be preferable to dial down the compilation 
settings for the fdlibm code rather than make a source code change. Was 
this investigated?

Thanks,

Brian

On Aug 28, 2018, at 7:18 AM, Andrew Leonard <andrew_m_leonard at uk.ibm.com> 
wrote:

We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's 
default compiler options has highlighted a couple of native code issues, 
with undefined behaviours:
 - validating loop test array bounds 
 - left shifts of negative values 
I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
and attached the webrev fix here: 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 

This has already been discussed and refined on the "s390x-port-dev" 
maillist
and as it was pointed out, it should have been posted here...

I'd like to request a sponsor for this fix please?




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From matthias.baesken at sap.com  Thu Aug 30 12:26:39 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 30 Aug 2018 12:26:39 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
Message-ID: <e76f3a3577af4797b858b16af7715e51@sap.com>

Hi Max, 

I changed the following in the new webrev :
- added the  copyright+license header to the new file
- called trim on each token

- adjusted the comment java.security  like you suggested

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/

> 
> - What will the output look like? Is it "/tmp/x.jar:100"?
>

Yes it look like this :

line too long (/testdata/jars/file_with_long_line_1.jar:2)


Best regards, Matthias



> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Mittwoch, 29. August 2018 16:27
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> SecurityProperties.java:
> 
> - Please add the copyright+license header to the new file.
> 
> - The "jdk.includeInExceptions" definition says there can be "Leading and
> trailing whitespaces". You might need to call trim() on each token.
> 
> java.security:
> 
> - I would suggest saying "classes from the java.util.jar package" or just "when
> parsing a jar file".
> 
> Others:
> 
> - What will the output look like? Is it "/tmp/x.jar:100"? If I read correctly, the
> line number is of the manifest and not the jar file.
> 
> Thanks
> Max
> 
> > On Aug 29, 2018, at 10:01 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hi Max, thanks for your input .
> >
> > I created another webrev , this contains now   the suggested
> SecurityProperties   class :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/
> >
> > Best regards, Matthias
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Weijun Wang <weijun.wang at oracle.com>
> >> Sent: Montag, 27. August 2018 17:35
> >> To: Baesken, Matthias <matthias.baesken at sap.com>
> >> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> >> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> >> parsing of jar archives
> >>
> >>
> >>
> >>> On Aug 27, 2018, at 10:25 PM, Baesken, Matthias
> >> <matthias.baesken at sap.com> wrote:
> >>>
> >>> Hi Alan ,
> >>>
> >>>> Will sun.net.util.SocketExceptions be changed to use the supporting
> >>>> class or is that a separate issue?
> >>>>
> >>>
> >>> I think this is a separate issue .
> >>>
> >>>> In terms of approach then I think what you have is okay although I think
> >>>> we should try to find a better name than
> "SecuritySystemPropertyHelper"
> >>>> and also get feedback from security-dev on whether they would prefer
> it
> >>>> in the sun.security tree with the other classes security classes.
> >>>
> >>> Suggestions are welcome , I  was a bit unsure about the name as well ?? !
> >>
> >> I am OK with creating a sun.security.util.SecurityProperties class, and a
> >> method called privilegeGetOverridable() for the 1st part of
> >> SecuritySystemPropertyHelper::initTextProperty (by overridable I mean a
> >> system property can shadow the security property). I have no idea where
> >> the 2nd part should go. Maybe you can just create an
> >> includedInExceptions(String refName) method for this purpose.
> >>
> >> So it will be something like this
> >>
> >> public class SecurityProperties {
> >>
> >>   public static String privilegeGetOverridable(String propName) {
> >>       return AccessController.doPrivileged((PrivilegedAction<String>)
> >>               () -> {
> >>                   String val = System.getProperty(propName);
> >>                   if (val == null) {
> >>                       return Security.getProperty(propName);
> >>                   } else {
> >>                       return val;
> >>                   }
> >>               });
> >>   }
> >>
> >>   public static boolean includedInExceptions(String refName) {
> >>       String val = privilegeGetOverridable("jdk.includeInExceptions");
> >>       if (val == null){
> >>           return false;
> >>       }
> >>       String[] tokens = val.split(",");
> >>       for (String token : tokens) {
> >>           if (token.equalsIgnoreCase(refName))
> >>               return true;
> >>       }
> >>       return false;
> >>   }
> >> }
> >>
> >> Thanks
> >> Max
> >>
> >>
> >>>
> >>> Thanks, Matthias
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alan Bateman <Alan.Bateman at oracle.com>
> >>>> Sent: Montag, 27. August 2018 15:52
> >>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Sean Mullan
> >>>> <sean.mullan at oracle.com>; Chris Hegarty
> <chris.hegarty at oracle.com>
> >>>> Cc: core-libs-dev at openjdk.java.net; security Dev OpenJDK <security-
> >>>> dev at openjdk.java.net>
> >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during
> manifest
> >>>> parsing of jar archives
> >>>>
> >>>> On 24/08/2018 15:52, Baesken, Matthias wrote:
> >>>>> Hello, I created another webrev :
> >>>>>
> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
> >>>>>
> >>>>> - use now  jarPath  instead of  jarpath  in the java security file
> >>>>> -  moved the parsing of the property  to a more general location
> >> (separate
> >>>> class jdk/internal/util/SecuritySystemPropertyHelper.java  )
> >>>>> -  read now  from the InputStream and check for error conditions
> >> *before*
> >>>> setting jarFilename    in the Manifest  constructor
> >>>>>
> >>>> Will sun.net.util.SocketExceptions be changed to use the supporting
> >>>> class or is that a separate issue?
> >>>>
> >>>> In terms of approach then I think what you have is okay although I think
> >>>> we should try to find a better name than
> "SecuritySystemPropertyHelper"
> >>>> and also get feedback from security-dev on whether they would prefer
> it
> >>>> in the sun.security tree with the other classes security classes.
> >>>>
> >>>> -Alan
> >


From magnus.ihse.bursie at oracle.com  Thu Aug 30 12:44:51 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 30 Aug 2018 14:44:51 +0200
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
Message-ID: <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>

Andrew,

If you want to make changes to the build system (files in make/*), 
please always include build-dev in the reviews.

 From a build point, this fix looks okay. My general preference is to 
fix shady code instead of disabling warnings, but in this case it's in 
two libraries that are either external or moribound, so if the 
maintainer's of the respective libraries want to avoid code changes, I 
accept that.

/Magnus


On 2018-08-30 14:18, Andrew Leonard wrote:
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   28/08/2018 15:52
> Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>
>
>
> Hi Andrew,
>
> It was suggested that it would be preferable to dial down the compilation
> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
>
> Thanks,
>
> Brian
>
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> wrote:
>
> We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's
> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>   - validating loop test array bounds
>   - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/
>
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
>
> I'd like to request a sponsor for this fix please?
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From andrew_m_leonard at uk.ibm.com  Thu Aug 30 13:03:17 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Thu, 30 Aug 2018 14:03:17 +0100
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
Message-ID: <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>

Thanks Magnus,
Yes, these libraries are moribound it seems, hence their preference for 
compile options..
Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 




From:   Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>, Brian Burkhalter 
<brian.burkhalter at oracle.com>
Cc:     core-libs-dev at openjdk.java.net, build-dev 
<build-dev at openjdk.java.net>
Date:   30/08/2018 13:49
Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux



Andrew,

If you want to make changes to the build system (files in make/*), 
please always include build-dev in the reviews.

 From a build point, this fix looks okay. My general preference is to 
fix shady code instead of disabling warnings, but in this case it's in 
two libraries that are either external or moribound, so if the 
maintainer's of the respective libraries want to avoid code changes, I 
accept that.

/Magnus


On 2018-08-30 14:18, Andrew Leonard wrote:
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/

> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   28/08/2018 15:52
> Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>
>
>
> Hi Andrew,
>
> It was suggested that it would be preferable to dial down the 
compilation
> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
>
> Thanks,
>
> Brian
>
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>
> wrote:
>
> We have discovered issues with gcc 7.3 on zLinux, combined with 
OpenJDK's
> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>   - validating loop test array bounds
>   - left shifts of negative values
> I have created bug 
https://bugs.openjdk.java.net/browse/JDK-8209786

> and attached the webrev fix here:
> 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/

>
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
>
> I'd like to request a sponsor for this fix please?
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From weijun.wang at oracle.com  Thu Aug 30 14:03:39 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 30 Aug 2018 22:03:39 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <e76f3a3577af4797b858b16af7715e51@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
Message-ID: <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>



> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> - What will the output look like? Is it "/tmp/x.jar:100"?
>> 
> 
> Yes it look like this :
> 
> line too long (/testdata/jars/file_with_long_line_1.jar:2)

Is this a little misleading? I think you mean

   /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2

Thanks
Max

From goetz.lindenmaier at sap.com  Thu Aug 30 14:36:28 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 30 Aug 2018 14:36:28 +0000
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
Message-ID: <093bf197ebd8480e8743c917eb36043a@sap.com>

Hi Leonard, 

the change looks good to me. 
I'll test it tonight, to make sure it runs with our compilers. 
Did you run it through jdk-submit?

If you supply a patch with all the changeset information (like 
from hg export) that jchecks fine, I'll sponsor this for you.

Best regards,
  Goetz.

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Andrew Leonard
> Sent: Donnerstag, 30. August 2018 14:19
> To: Brian Burkhalter <brian.burkhalter at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
> 
> 
> 
> 
> From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   28/08/2018 15:52
> Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> 
> 
> Hi Andrew,
> 
> It was suggested that it would be preferable to dial down the compilation
> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
> 
> Thanks,
> 
> Brian
> 
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> <andrew_m_leonard at uk.ibm.com>
> wrote:
> 
> We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's
> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>  - validating loop test array bounds
>  - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/
> 
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
> 
> I'd like to request a sponsor for this fix please?
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU

From matthias.baesken at sap.com  Thu Aug 30 14:50:57 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 30 Aug 2018 14:50:57 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
 <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
Message-ID: <eb76647f7bff4042a692b39190179034@sap.com>



Hi  Max, probably   we should add  the  info about the MANIFEST.MF  , for example :
 change  getErrorPosition  to 

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/share/classes/java/util/jar/Attributes.java.udiff.html


    static String getErrorPosition(String filename, final int lineNumber) {
        if (filename == null || !jarPathInExceptionText) {
            return "META-INF/MANIFEST.MF  line:" + lineNumber;
       }

       final File file = new File(filename);
        return AccessController.doPrivileged(new PrivilegedAction<String>() {
            public String run() {
                return file.getAbsolutePath() + "!META-INF/MANIFEST.MF  line:" + lineNumber;
         }
   .....


Best regards, Matthias



> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Donnerstag, 30. August 2018 16:04
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> 
> 
> > On Aug 30, 2018, at 8:26 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> >> - What will the output look like? Is it "/tmp/x.jar:100"?
> >>
> >
> > Yes it look like this :
> >
> > line too long (/testdata/jars/file_with_long_line_1.jar:2)
> 
> Is this a little misleading? I think you mean
> 
>    /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2
> 
> Thanks
> Max

From andrew_m_leonard at uk.ibm.com  Thu Aug 30 15:01:54 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Thu, 30 Aug 2018 16:01:54 +0100
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <093bf197ebd8480e8743c917eb36043a@sap.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <093bf197ebd8480e8743c917eb36043a@sap.com>
Message-ID: <OFBA39161F.C38C16B2-ON802582F9.005261D6-802582F9.00528D1A@notes.na.collabserv.com>

Thanks Goetz,
I've created an hg export below..
I've not used jdk-submit, i've tested it locally on xLinux and zLinux.
Cheers
Andrew

# HG changeset patch
# User aleonard
# Date 1535641094 -3600
#      Thu Aug 30 15:58:14 2018 +0100
# Node ID 592a8ad8d4c16287c316d018a0a402148720718b
# Parent  1ddd1ec044311512c55643bed641859e78b9d25e
8209786: disable gcc warnings for libmlib & libfdlibm to enable gcc 7.3 on 
zLinux

diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk       Thu Aug 30 09:08:23 2018 -0400
+++ b/make/lib/Awt2dLibraries.gmk       Thu Aug 30 15:58:14 2018 +0100
@@ -55,6 +55,7 @@
     OPTIMIZATION := HIGHEST, \
     CFLAGS := $(CFLAGS_JDKLIB) \
         $(BUILD_LIBMLIB_CFLAGS), \
+    DISABLED_WARNINGS_gcc := shift-negative-value, \
     LDFLAGS := $(LDFLAGS_JDKLIB) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
     LIBS := $(JDKLIB_LIBS), \
diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/CoreLibraries.gmk
--- a/make/lib/CoreLibraries.gmk        Thu Aug 30 09:08:23 2018 -0400
+++ b/make/lib/CoreLibraries.gmk        Thu Aug 30 15:58:14 2018 +0100
@@ -68,7 +68,7 @@
       CFLAGS_linux_ppc64le := -ffp-contract=off, \
       CFLAGS_linux_s390x := -ffp-contract=off, \
       CFLAGS_linux_aarch64 := -ffp-contract=off, \
-      DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
+      DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
array-bounds, \
       DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
       ARFLAGS := $(ARFLAGS), \
       OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \




Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 




From:   "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>, Brian Burkhalter 
<brian.burkhalter at oracle.com>
Cc:     "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>, 
"build-dev (build-dev at openjdk.java.net)" <build-dev at openjdk.java.net>
Date:   30/08/2018 15:36
Subject:        RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux



Hi Leonard, 

the change looks good to me. 
I'll test it tonight, to make sure it runs with our compilers. 
Did you run it through jdk-submit?

If you supply a patch with all the changeset information (like 
from hg export) that jchecks fine, I'll sponsor this for you.

Best regards,
  Goetz.

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Andrew Leonard
> Sent: Donnerstag, 30. August 2018 14:19
> To: Brian Burkhalter <brian.burkhalter at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/

> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
> 
> 
> 
> 
> From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   28/08/2018 15:52
> Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> 
> 
> Hi Andrew,
> 
> It was suggested that it would be preferable to dial down the 
compilation
> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
> 
> Thanks,
> 
> Brian
> 
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> <andrew_m_leonard at uk.ibm.com>
> wrote:
> 
> We have discovered issues with gcc 7.3 on zLinux, combined with 
OpenJDK's
> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>  - validating loop test array bounds
>  - left shifts of negative values
> I have created bug 
https://bugs.openjdk.java.net/browse/JDK-8209786

> and attached the webrev fix here:
> 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/

> 
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
> 
> I'd like to request a sponsor for this fix please?
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From maurizio.cimadamore at oracle.com  Thu Aug 30 15:12:40 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 30 Aug 2018 16:12:40 +0100
Subject: RFR 8210226: Add support for multiple project folders to idea.sh
Message-ID: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>

Hi,
this patch adds proper support for -o option to the idea.sh script, 
which allows to place the .idea folder under any given output folder 
(not necessarily the JDK root).

To be able to do this, I had to revampo the logic for template 
substitution in idea.sh, as it was growing too brittle. I now have a 
much more declarative logic, where replacements can be added by calling 
the add_replacement function. This allows to replace a lot of the 
previous code with very simple and self-explanatory calls to that routine.

This piece was necessary, as we needed to replace a lot of references to 
the idea variable $PROJECT_DIR with the new template variable 
###ROOT_DIR### (otherwise the project is ill-formed, since $PROJECT_DIR 
merely points at the folder containing the .idea project folder).

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210226/

Cheers
Maurizio


From james.laskey at oracle.com  Thu Aug 30 15:31:35 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 30 Aug 2018 12:31:35 -0300
Subject: RFR - JDK-8200434 - String::align, String::indent (code review)
In-Reply-To: <32e6536a-19bf-fafd-9eb8-6a5ff2fa35bb@oracle.com>
References: <866B7282-D7B1-4B63-9497-B43D7D84AC6C@oracle.com>
 <32e6536a-19bf-fafd-9eb8-6a5ff2fa35bb@oracle.com>
Message-ID: <952AA42E-AB6E-44F8-B1F0-483892619A27@oracle.com>

The special case for non-multiline strings aside, look at the following example;
	String s = "abc\ndef\nghi\n";
	System.out.println(s.lines().collect(Collectors.joining("\n", "", "\n")).lines().count());
	System.out.println(s.lines().collect(Collectors.joining("\n")).lines().count());
As expected the result is 

3
3

Now try 

	String s = "abc\ndef\n\n";
	System.out.println(s.lines().collect(Collectors.joining("\n", "", "\n")).lines().count());
	System.out.println(s.lines().collect(Collectors.joining("\n")).lines().count());

The result is now

3
2

We started with 3 lines but ended up with 2 lines. This is because String::split(?\\R?), BufferedReader?::lines() and String::lines() have the definition of line-ness as
* A <i>line</i> is either a sequence of zero or more characters
* followed by a line terminator, or it is a sequence of one or
* more characters followed by the end of the string. A
* line does not include the line terminator.
So if we didn?t add the final line terminator, then we would drop a line every time we had an empty line at the end of the string.

Adding to the cases above

	String s = "abc\ndef\n   \n".indent(-3);
	System.out.println(s.lines().collect(Collectors.joining("\n", "", "\n")).lines().count());
	System.out.println(s.lines().collect(Collectors.joining("\n")).lines().count());
Would also result in

3
2

Thus, it is a line terminator and not a line separator. As a bonus. the use cases we see with String::indent(int n) are consistent with having a final line terminator.

	String composite = head.indent(4) + body.indent(8) + tail.indent(4);
vs
	String composite = head.indent(4) + "\n" + body.indent(8) + "\n" + tail.indent(4) + "\n";

Your point about consistency with non-multiline is valid, and we will drop the special case since it is inconsistent with the spec. The correction will treat non-multiline strings as single line.  (Adding indentation to simple strings can easily be done with " ".repeat(n) and removing indentation with s.substring(n).)

Note:

	"a single line".lines().count() == 1
	"".lines().count() == 0

Cheers,

? Jim


> On Aug 29, 2018, at 6:48 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hi Jim!
> 
> Why a new line is always added to the result of indent(int):
> 
> return stream.collect(Collectors.joining("\n", "", "\n"));
> Because of this, a call to str.indent(0) depends on whether the string is single-line or multi-line: In the former case it is unchanged, while in the later case it gets a newline appended.
> Moreover, if a multi-line string already ends with a new line, then a new new-line is not appended, which seems inconsistent.
> 
> I think, it may be better to always preserve the number of existing trailing new lines.
> 
> With kind regards,
> Ivan
> 
> 
> On 8/29/18 7:00 AM, Jim Laskey wrote:
>> Please review the code  for  String::align and String::indent at the link below.
>> 
>> Notes:
>> 	Includes a private version of String::isMultiline() which may be made into a public method at some future date
>> 	Includes minor correctness clean up of StringLatin1.java, StringUTF16.java
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8200434 <https://bugs.openjdk.java.net/browse/JDK-8200434>
>> 
>> Cheers,
>> 
>> ? Jim
>> 
>> 
> 
> -- 
> With kind regards,
> Ivan Gerasimov


From erik.joelsson at oracle.com  Thu Aug 30 18:07:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 30 Aug 2018 11:07:28 -0700
Subject: RFR 8210226: Add support for multiple project folders to idea.sh
In-Reply-To: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
References: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
Message-ID: <71a4e834-f8c5-8526-b665-a74501b5aca4@oracle.com>

Looks good to me.

/Erik


On 2018-08-30 08:12, Maurizio Cimadamore wrote:
> Hi,
> this patch adds proper support for -o option to the idea.sh script, 
> which allows to place the .idea folder under any given output folder 
> (not necessarily the JDK root).
>
> To be able to do this, I had to revampo the logic for template 
> substitution in idea.sh, as it was growing too brittle. I now have a 
> much more declarative logic, where replacements can be added by 
> calling the add_replacement function. This allows to replace a lot of 
> the previous code with very simple and self-explanatory calls to that 
> routine.
>
> This piece was necessary, as we needed to replace a lot of references 
> to the idea variable $PROJECT_DIR with the new template variable 
> ###ROOT_DIR### (otherwise the project is ill-formed, since 
> $PROJECT_DIR merely points at the folder containing the .idea project 
> folder).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210226/
>
> Cheers
> Maurizio
>


From brian.burkhalter at oracle.com  Thu Aug 30 22:37:47 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 30 Aug 2018 15:37:47 -0700
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
Message-ID: <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>

Hi Andrew,

As noted in the issue comments, the fdlibm C code is obsolescent and eventually to be superseded by equivalent Java implementations. As for the mediaLib code being moribund I cannot speak but am copying 2d-dev which owns java.desktop.

Thanks,

Brian

On Aug 30, 2018, at 6:03 AM, Andrew Leonard <andrew_m_leonard at uk.ibm.com> wrote:

> Thanks Magnus, 
> Yes, these libraries are moribound it seems, hence their preference for compile options.. 
> Cheers 
> Andrew 
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com 
> 
> 
> 
> 
> From:        Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> 
> To:        Andrew Leonard <andrew_m_leonard at uk.ibm.com>, Brian Burkhalter <brian.burkhalter at oracle.com> 
> Cc:        core-libs-dev at openjdk.java.net, build-dev <build-dev at openjdk.java.net> 
> Date:        30/08/2018 13:49 
> Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux 
> 
> 
> 
> Andrew,
> 
> If you want to make changes to the build system (files in make/*), 
> please always include build-dev in the reviews.
> 
> From a build point, this fix looks okay. My general preference is to 
> fix shady code instead of disabling warnings, but in this case it's in 
> two libraries that are either external or moribound, so if the 
> maintainer's of the respective libraries want to avoid code changes, I 
> accept that.
> 
> /Magnus
> 
> 
> On 2018-08-30 14:18, Andrew Leonard wrote:
> > Hi Brian,
> > Thanks for taking a look at this, I have just done a rebuild with a new
> > patch with appropriate gcc disable warnings for these libraries:
> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> > This works fine, so if you think this is a more favourable approach for
> > these libraries? i'd like to get this merged please.
> > Thanks
> > Andrew
> >
> > Andrew Leonard
> > Java Runtimes Development
> > IBM Hursley
> > IBM United Kingdom Ltd
> > Phone internal: 245913, external: 01962 815913
> > internet email: andrew_m_leonard at uk.ibm.com
> >
> >
> >
> >
> > From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> > To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> > Cc:     core-libs-dev at openjdk.java.net
> > Date:   28/08/2018 15:52
> > Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >
> >
> >
> > Hi Andrew,
> >
> > It was suggested that it would be preferable to dial down the compilation
> > settings for the fdlibm code rather than make a source code change. Was
> > this investigated?
> >
> > Thanks,
> >
> > Brian
> >
> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> > wrote:
> >
> > We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's
> > default compiler options has highlighted a couple of native code issues,
> > with undefined behaviours:
> >   - validating loop test array bounds
> >   - left shifts of negative values
> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> > and attached the webrev fix here:
> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/
> >
> > This has already been discussed and refined on the "s390x-port-dev"
> > maillist
> > and as it was pointed out, it should have been posted here...
> >
> > I'd like to request a sponsor for this fix please?
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From philip.race at oracle.com  Thu Aug 30 23:28:09 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 30 Aug 2018 16:28:09 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
 <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
Message-ID: <5B887D89.9070201@oracle.com>

Some day, I'd like to replace a lot of medialib functionality with something
like the proposed Vector API. But that is far enough away that medialib 
needs
to be maintained, and unlike a previous discussion about a similar issue in
the JPEG library, we are on the hook for maintaining medialib.
So if there is an actual logic error in medialib, I'd prefer to fix it.
If the issue is a false positive, I'd be OK to disable the warning, but 
wrapped
in a platform-specific manner. So is it a real error here ?

-phil.

On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
> Hi Andrew,
>
> As noted in the issue comments, the fdlibm C code is obsolescent and 
> eventually to be superseded by equivalent Java implementations. As for 
> the mediaLib code being moribund I cannot speak but am copying 2d-dev 
> which owns java.desktop.
>
> Thanks,
>
> Brian
>
> On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>> wrote:
>
>> Thanks Magnus,
>> Yes, these libraries are moribound it seems, hence their preference 
>> for compile options..
>> Cheers
>> Andrew
>>
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> Phone internal: 245913, external: 01962 815913
>> internet email: andrew_m_leonard at uk.ibm.com 
>> <mailto:andrew_m_leonard at uk.ibm.com>
>>
>>
>>
>>
>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com 
>> <mailto:magnus.ihse.bursie at oracle.com>>
>> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>> <mailto:andrew_m_leonard at uk.ibm.com>>, Brian Burkhalter 
>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>>
>> Cc: core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>, build-dev 
>> <build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>>
>> Date: 30/08/2018 13:49
>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>> ------------------------------------------------------------------------
>>
>>
>>
>> Andrew,
>>
>> If you want to make changes to the build system (files in make/*),
>> please always include build-dev in the reviews.
>>
>> From a build point, this fix looks okay. My general preference is to
>> fix shady code instead of disabling warnings, but in this case it's in
>> two libraries that are either external or moribound, so if the
>> maintainer's of the respective libraries want to avoid code changes, I
>> accept that.
>>
>> /Magnus
>>
>>
>> On 2018-08-30 14:18, Andrew Leonard wrote:
>> > Hi Brian,
>> > Thanks for taking a look at this, I have just done a rebuild with a new
>> > patch with appropriate gcc disable warnings for these libraries:
>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/>
>> > This works fine, so if you think this is a more favourable approach for
>> > these libraries? i'd like to get this merged please.
>> > Thanks
>> > Andrew
>> >
>> > Andrew Leonard
>> > Java Runtimes Development
>> > IBM Hursley
>> > IBM United Kingdom Ltd
>> > Phone internal: 245913, external: 01962 815913
>> > internet email: andrew_m_leonard at uk.ibm.com 
>> <mailto:andrew_m_leonard at uk.ibm.com>
>> >
>> >
>> >
>> >
>> > From:   Brian Burkhalter <brian.burkhalter at oracle.com 
>> <mailto:brian.burkhalter at oracle.com>>
>> > To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>> <mailto:andrew_m_leonard at uk.ibm.com>>
>> > Cc: core-libs-dev at openjdk.java.net 
>> <mailto:core-libs-dev at openjdk.java.net>
>> > Date:   28/08/2018 15:52
>> > Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>> >
>> >
>> >
>> > Hi Andrew,
>> >
>> > It was suggested that it would be preferable to dial down the 
>> compilation
>> > settings for the fdlibm code rather than make a source code change. Was
>> > this investigated?
>> >
>> > Thanks,
>> >
>> > Brian
>> >
>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>>
>> > wrote:
>> >
>> > We have discovered issues with gcc 7.3 on zLinux, combined with 
>> OpenJDK's
>> > default compiler options has highlighted a couple of native code issues,
>> > with undefined behaviours:
>> >   - validating loop test array bounds
>> >   - left shifts of negative values
>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
>> > and attached the webrev fix here:
>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>
>> >
>> > This has already been discussed and refined on the "s390x-port-dev"
>> > maillist
>> > and as it was pointed out, it should have been posted here...
>> >
>> > I'd like to request a sponsor for this fix please?
>> >
>> >
>> >
>> >
>> > Unless stated otherwise above:
>> > IBM United Kingdom Limited - Registered in England and Wales with number
>> > 741598.
>> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>> PO6 3AU
>>
>>
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>> PO6 3AU
>

From xu.y.yin at oracle.com  Fri Aug 31 01:07:48 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 31 Aug 2018 09:07:48 +0800
Subject: [12] RFR 8209773: Refactor shell test
 javax/naming/module/basic.sh to java
In-Reply-To: <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>
References: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
 <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>
Message-ID: <859DD0AE-A17A-4845-A9F6-74569B802E90@oracle.com>

Thank you, Vyom

Regards,
Chris

> On 30 Aug 2018, at 5:06 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> The refactored  java class (RunBasic.java) looks good to me.
> 
> Thanks,
> 
> Vyom
> 
> 
> On Tuesday 28 August 2018 11:20 AM, Chris Yin wrote:
>> Please have a review for below change to refactor shell test javax/naming/module/basic.sh to plain java, no test logic change, old shell script is removed at same time, thanks
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209773
>> webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/
>> 
>> Regards,
>> Chris
> 


From weijun.wang at oracle.com  Fri Aug 31 02:32:08 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 31 Aug 2018 10:32:08 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <eb76647f7bff4042a692b39190179034@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
 <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
 <eb76647f7bff4042a692b39190179034@sap.com>
Message-ID: <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>

Some more comments:

Attributes.java

- No need to "import java.security.Security".

- In the updated read() method, I think there is no need to use an "int offset" parameter. "int lineNumber" is enough and you can modify it and return it without a new local variable.

- I feel like calling Attributes::getErrorPosition from Manifest a little strange. Maybe it's better to define the method in Manifest and call it from Attributes. First, I think putting the method in a higher level object makes more sense. Second, the position is for the whole Manifest and not an Attributes section (I mean the line number is counted from the first line of the manifest).

> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> 
> 
> Hi  Max, probably   we should add  the  info about the MANIFEST.MF  , for example :
> change  getErrorPosition  to 
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/share/classes/java/util/jar/Attributes.java.udiff.html
> 
> 
>    static String getErrorPosition(String filename, final int lineNumber) {
>        if (filename == null || !jarPathInExceptionText) {
>            return "META-INF/MANIFEST.MF  line:" + lineNumber;
>       }
> 
>       final File file = new File(filename);
>        return AccessController.doPrivileged(new PrivilegedAction<String>() {
>            public String run() {
>                return file.getAbsolutePath() + "!META-INF/MANIFEST.MF  line:" + lineNumber;

I prefer "file:line" which is more compact and more commonly used.

In fact, I have a small concern on the hardcoded file name here, because when verifying a signed jar, the META-INF/X.SF file is also parsed into a Manifest object and if it's invalid similar exceptions will be thrown. I don't have a nice solution now. if we want to show the .SF name also, we will need a public API because SignatureFileVerifier.java is inside sun.security.util. Something like Manifest(InputStream,jarName,entryName)?

Sorry for making this complicated.

Thanks
Max

>         }
>   .....
> 
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Weijun Wang <weijun.wang at oracle.com>
>> Sent: Donnerstag, 30. August 2018 16:04
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>> 
>> 
>> 
>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>>> - What will the output look like? Is it "/tmp/x.jar:100"?
>>>> 
>>> 
>>> Yes it look like this :
>>> 
>>> line too long (/testdata/jars/file_with_long_line_1.jar:2)
>> 
>> Is this a little misleading? I think you mean
>> 
>>   /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2
>> 
>> Thanks
>> Max


From weijun.wang at oracle.com  Fri Aug 31 02:36:58 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 31 Aug 2018 10:36:58 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
 <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
 <eb76647f7bff4042a692b39190179034@sap.com>
 <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>
Message-ID: <B18C5A04-4683-4811-BF5B-95BE351FC53E@oracle.com>

Or you can smuggle it out through JavaUtilJarAccess with SharedSecrets.

> On Aug 31, 2018, at 10:32 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> if we want to show the .SF name also, we will need a public API because SignatureFileVerifier.java is inside sun.security.util. Something like Manifest(InputStream,jarName,entryName)?


From goetz.lindenmaier at sap.com  Fri Aug 31 06:50:23 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 31 Aug 2018 06:50:23 +0000
Subject: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
In-Reply-To: <OFBA39161F.C38C16B2-ON802582F9.005261D6-802582F9.00528D1A@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <093bf197ebd8480e8743c917eb36043a@sap.com>
 <OFBA39161F.C38C16B2-ON802582F9.005261D6-802582F9.00528D1A@notes.na.collabserv.com>
Message-ID: <1549d6b8e9bc46ccad1df989b71b83f6@sap.com>

Hi Leonard,

Whom should I add as reviewers?  (Besides me :))

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Sent: Donnerstag, 30. August 2018 17:02
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Brian Burkhalter <brian.burkhalter at oracle.com>; build-dev (build-
> dev at openjdk.java.net) <build-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net
> Subject: RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> Thanks Goetz,
> I've created an hg export below..
> I've not used jdk-submit, i've tested it locally on xLinux and zLinux.
> Cheers
> Andrew
> 
> # HG changeset patch
> # User aleonard
> # Date 1535641094 -3600
> #      Thu Aug 30 15:58:14 2018 +0100
> # Node ID 592a8ad8d4c16287c316d018a0a402148720718b
> # Parent  1ddd1ec044311512c55643bed641859e78b9d25e
> 8209786: disable gcc warnings for libmlib & libfdlibm to enable gcc 7.3 on
> zLinux
> 
> diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk       Thu Aug 30 09:08:23 2018 -0400
> +++ b/make/lib/Awt2dLibraries.gmk       Thu Aug 30 15:58:14 2018 +0100
> @@ -55,6 +55,7 @@
>      OPTIMIZATION := HIGHEST, \
>      CFLAGS := $(CFLAGS_JDKLIB) \
>          $(BUILD_LIBMLIB_CFLAGS), \
> +    DISABLED_WARNINGS_gcc := shift-negative-value, \
>      LDFLAGS := $(LDFLAGS_JDKLIB) \
>          $(call SET_SHARED_LIBRARY_ORIGIN), \
>      LIBS := $(JDKLIB_LIBS), \
> diff -r 1ddd1ec04431 -r 592a8ad8d4c1 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmk        Thu Aug 30 09:08:23 2018 -0400
> +++ b/make/lib/CoreLibraries.gmk        Thu Aug 30 15:58:14 2018 +0100
> @@ -68,7 +68,7 @@
>        CFLAGS_linux_ppc64le := -ffp-contract=off, \
>        CFLAGS_linux_s390x := -ffp-contract=off, \
>        CFLAGS_linux_aarch64 := -ffp-contract=off, \
> -      DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
> +      DISABLED_WARNINGS_gcc := sign-compare misleading-indentation
> array-bounds, \
>        DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>        ARFLAGS := $(ARFLAGS), \
>        OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \
> 
> 
> 
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
> 
> 
> 
> 
> From:        "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
> To:        Andrew Leonard <andrew_m_leonard at uk.ibm.com>, Brian
> Burkhalter <brian.burkhalter at oracle.com>
> Cc:        "core-libs-dev at openjdk.java.net" <core-libs-
> dev at openjdk.java.net>, "build-dev (build-dev at openjdk.java.net)" <build-
> dev at openjdk.java.net>
> Date:        30/08/2018 15:36
> Subject:        RE: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> 
> ________________________________
> 
> 
> 
> 
> Hi Leonard,
> 
> the change looks good to me.
> I'll test it tonight, to make sure it runs with our compilers.
> Did you run it through jdk-submit?
> 
> If you supply a patch with all the changeset information (like
> from hg export) that jchecks fine, I'll sponsor this for you.
> 
> Best regards,
>  Goetz.
> 
> > -----Original Message-----
> > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> > Of Andrew Leonard
> > Sent: Donnerstag, 30. August 2018 14:19
> > To: Brian Burkhalter <brian.burkhalter at oracle.com>
> > Cc: core-libs-dev at openjdk.java.net
> > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >
> > Hi Brian,
> > Thanks for taking a look at this, I have just done a rebuild with a new
> > patch with appropriate gcc disable warnings for these libraries:
> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/
> <http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/>
> > This works fine, so if you think this is a more favourable approach for
> > these libraries? i'd like to get this merged please.
> > Thanks
> > Andrew
> >
> > Andrew Leonard
> > Java Runtimes Development
> > IBM Hursley
> > IBM United Kingdom Ltd
> > Phone internal: 245913, external: 01962 815913
> > internet email: andrew_m_leonard at uk.ibm.com
> >
> >
> >
> >
> > From:   Brian Burkhalter <brian.burkhalter at oracle.com>
> > To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> > Cc:     core-libs-dev at openjdk.java.net
> > Date:   28/08/2018 15:52
> > Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >
> >
> >
> > Hi Andrew,
> >
> > It was suggested that it would be preferable to dial down the compilation
> > settings for the fdlibm code rather than make a source code change. Was
> > this investigated?
> >
> > Thanks,
> >
> > Brian
> >
> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> > <andrew_m_leonard at uk.ibm.com>
> > wrote:
> >
> > We have discovered issues with gcc 7.3 on zLinux, combined with
> OpenJDK's
> > default compiler options has highlighted a couple of native code issues,
> > with undefined behaviours:
> >  - validating loop test array bounds
> >  - left shifts of negative values
> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> <https://bugs.openjdk.java.net/browse/JDK-8209786>
> > and attached the webrev fix here:
> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/
> <http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/>
> >
> > This has already been discussed and refined on the "s390x-port-dev"
> > maillist
> > and as it was pointed out, it should have been posted here...
> >
> > I'd like to request a sponsor for this fix please?
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU


From magnus.ihse.bursie at oracle.com  Fri Aug 31 07:36:22 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 31 Aug 2018 09:36:22 +0200
Subject: RFR 8210226: Add support for multiple project folders to idea.sh
In-Reply-To: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
References: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
Message-ID: <dd85a187-4ac5-37b0-ba51-7ac978a47706@oracle.com>

On 2018-08-30 17:12, Maurizio Cimadamore wrote:
> Hi,
> this patch adds proper support for -o option to the idea.sh script, 
> which allows to place the .idea folder under any given output folder 
> (not necessarily the JDK root).
>
> To be able to do this, I had to revampo the logic for template 
> substitution in idea.sh, as it was growing too brittle. I now have a 
> much more declarative logic, where replacements can be added by 
> calling the add_replacement function. This allows to replace a lot of 
> the previous code with very simple and self-explanatory calls to that 
> routine.
>
> This piece was necessary, as we needed to replace a lot of references 
> to the idea variable $PROJECT_DIR with the new template variable 
> ###ROOT_DIR### (otherwise the project is ill-formed, since 
> $PROJECT_DIR merely points at the folder containing the .idea project 
> folder).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210226/

Looks good to me, with the caveat that I do not fully understand the 
idea project generator.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Aug 31 08:27:26 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 31 Aug 2018 10:27:26 +0200
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <5B887D89.9070201@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
 <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
 <5B887D89.9070201@oracle.com>
Message-ID: <6163c668-1584-bc17-de92-26e518830cdf@oracle.com>

On 2018-08-31 01:28, Philip Race wrote:
> Some day, I'd like to replace a lot of medialib functionality with 
> something
> like the proposed Vector API. But that is far enough away that 
> medialib needs
> to be maintained, and unlike a previous discussion about a similar 
> issue in
> the JPEG library, we are on the hook for maintaining medialib.
> So if there is an actual logic error in medialib, I'd prefer to fix it.
> If the issue is a false positive, I'd be OK to disable the warning, 
> but wrapped
> in a platform-specific manner. So is it a real error here ?

Gcc is emitting a warning due to shifting of negative values, which is 
deemed undefined behavior by the spec.

Is this a real error? Well. Undefined behavior is no good. It can work 
for now and then suddenly start breaking.

The originally suggested code change 
(http://cr.openjdk.java.net/~aleonard/8209786/webrev.00) seems 
reasonable to me. It is at the very least much clearer what the 
intention is. And it's conformant with the spec.

So I'd advocate using that fix, if you want to continue supporting the 
library.

/Magnus




>
> -phil.
>
> On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
>> Hi Andrew,
>>
>> As noted in the issue comments, the fdlibm C code is obsolescent and 
>> eventually to be superseded by equivalent Java implementations. As 
>> for the mediaLib code being moribund I cannot speak but am copying 
>> 2d-dev which owns java.desktop.
>>
>> Thanks,
>>
>> Brian
>>
>> On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>> 
>> wrote:
>>
>>> Thanks Magnus,
>>> Yes, these libraries are moribound it seems, hence their preference 
>>> for compile options..
>>> Cheers
>>> Andrew
>>>
>>> Andrew Leonard
>>> Java Runtimes Development
>>> IBM Hursley
>>> IBM United Kingdom Ltd
>>> Phone internal: 245913, external: 01962 815913
>>> internet email: andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>
>>>
>>>
>>>
>>>
>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com 
>>> <mailto:magnus.ihse.bursie at oracle.com>>
>>> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>>, Brian Burkhalter 
>>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>>
>>> Cc: core-libs-dev at openjdk.java.net 
>>> <mailto:core-libs-dev at openjdk.java.net>, build-dev 
>>> <build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>>
>>> Date: 30/08/2018 13:49
>>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
>>>
>>> Andrew,
>>>
>>> If you want to make changes to the build system (files in make/*),
>>> please always include build-dev in the reviews.
>>>
>>> From a build point, this fix looks okay. My general preference is to
>>> fix shady code instead of disabling warnings, but in this case it's in
>>> two libraries that are either external or moribound, so if the
>>> maintainer's of the respective libraries want to avoid code changes, I
>>> accept that.
>>>
>>> /Magnus
>>>
>>>
>>> On 2018-08-30 14:18, Andrew Leonard wrote:
>>> > Hi Brian,
>>> > Thanks for taking a look at this, I have just done a rebuild with 
>>> a new
>>> > patch with appropriate gcc disable warnings for these libraries:
>>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/>
>>> > This works fine, so if you think this is a more favourable 
>>> approach for
>>> > these libraries? i'd like to get this merged please.
>>> > Thanks
>>> > Andrew
>>> >
>>> > Andrew Leonard
>>> > Java Runtimes Development
>>> > IBM Hursley
>>> > IBM United Kingdom Ltd
>>> > Phone internal: 245913, external: 01962 815913
>>> > internet email: andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>
>>> >
>>> >
>>> >
>>> >
>>> > From:?? Brian Burkhalter <brian.burkhalter at oracle.com 
>>> <mailto:brian.burkhalter at oracle.com>>
>>> > To:???? Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>>
>>> > Cc: core-libs-dev at openjdk.java.net 
>>> <mailto:core-libs-dev at openjdk.java.net>
>>> > Date:?? 28/08/2018 15:52
>>> > Subject:??????? Re: RFR JDK-8209786: gcc 7.3 compiler errors on 
>>> zLinux
>>> >
>>> >
>>> >
>>> > Hi Andrew,
>>> >
>>> > It was suggested that it would be preferable to dial down the 
>>> compilation
>>> > settings for the fdlibm code rather than make a source code 
>>> change. Was
>>> > this investigated?
>>> >
>>> > Thanks,
>>> >
>>> > Brian
>>> >
>>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
>>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>>
>>> > wrote:
>>> >
>>> > We have discovered issues with gcc 7.3 on zLinux, combined with 
>>> OpenJDK's
>>> > default compiler options has highlighted a couple of native code 
>>> issues,
>>> > with undefined behaviours:
>>> >?? - validating loop test array bounds
>>> >?? - left shifts of negative values
>>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
>>> > and attached the webrev fix here:
>>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>
>>> >
>>> > This has already been discussed and refined on the "s390x-port-dev"
>>> > maillist
>>> > and as it was pointed out, it should have been posted here...
>>> >
>>> > I'd like to request a sponsor for this fix please?
>>> >
>>> >
>>> >
>>> >
>>> > Unless stated otherwise above:
>>> > IBM United Kingdom Limited - Registered in England and Wales with 
>>> number
>>> > 741598.
>>> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>>> PO6 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with 
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>>> PO6 3AU
>>


From andrew_m_leonard at uk.ibm.com  Fri Aug 31 09:14:34 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Fri, 31 Aug 2018 10:14:34 +0100
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <6163c668-1584-bc17-de92-26e518830cdf@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
 <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
 <5B887D89.9070201@oracle.com>
 <6163c668-1584-bc17-de92-26e518830cdf@oracle.com>
Message-ID: <OF2A92E894.CE374AFC-ON802582FA.00317DC3-802582FA.0032C01A@notes.na.collabserv.com>

Hi,
So there seems to be varying opinion here, taking the 2D view point since 
it is going to be maintained, the opinion seems to be more with the fix (
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/). This would be my 
personal preference also, but previous comments seemed to prefer compiler 
options.

Looking at each error:
- /libfdlibm/k_rem_pio2.c : This is a simple "for" loop bound check, which 
with good programming practice should really have been there to prevent 
ArrayOutOfBounds.. or native overwrites.. Simple fix.
- libmlib_image/mlib_ImageLookUp_Bit.c : This is -ve bit shifting which is 
spec undefined, which in theory could mean it breaks in the future if we 
upgrade/change compiler... However, this is complex code, we need to be 
very sure the new fix is "correct", myself and my colleague here have 
examined it closely and are happy, but i'd appreciate your in-depth 
analysis please. 

Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or 
"DisableWarnings" ?

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 




From:   Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
To:     Philip Race <philip.race at oracle.com>, Brian Burkhalter 
<brian.burkhalter at oracle.com>
Cc:     2d-dev <2d-dev at openjdk.java.net>, build-dev 
<build-dev at openjdk.java.net>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>, core-libs-dev 
<core-libs-dev at openjdk.java.net>
Date:   31/08/2018 09:27
Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux



On 2018-08-31 01:28, Philip Race wrote:
> Some day, I'd like to replace a lot of medialib functionality with 
> something
> like the proposed Vector API. But that is far enough away that 
> medialib needs
> to be maintained, and unlike a previous discussion about a similar 
> issue in
> the JPEG library, we are on the hook for maintaining medialib.
> So if there is an actual logic error in medialib, I'd prefer to fix it.
> If the issue is a false positive, I'd be OK to disable the warning, 
> but wrapped
> in a platform-specific manner. So is it a real error here ?

Gcc is emitting a warning due to shifting of negative values, which is 
deemed undefined behavior by the spec.

Is this a real error? Well. Undefined behavior is no good. It can work 
for now and then suddenly start breaking.

The originally suggested code change 
(
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00
) seems 
reasonable to me. It is at the very least much clearer what the 
intention is. And it's conformant with the spec.

So I'd advocate using that fix, if you want to continue supporting the 
library.

/Magnus




>
> -phil.
>
> On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
>> Hi Andrew,
>>
>> As noted in the issue comments, the fdlibm C code is obsolescent and 
>> eventually to be superseded by equivalent Java implementations. As 
>> for the mediaLib code being moribund I cannot speak but am copying 
>> 2d-dev which owns java.desktop.
>>
>> Thanks,
>>
>> Brian
>>
>> On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>> 
>> wrote:
>>
>>> Thanks Magnus,
>>> Yes, these libraries are moribound it seems, hence their preference 
>>> for compile options..
>>> Cheers
>>> Andrew
>>>
>>> Andrew Leonard
>>> Java Runtimes Development
>>> IBM Hursley
>>> IBM United Kingdom Ltd
>>> Phone internal: 245913, external: 01962 815913
>>> internet email: andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>
>>>
>>>
>>>
>>>
>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com 
>>> <mailto:magnus.ihse.bursie at oracle.com>>
>>> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>>, Brian Burkhalter 
>>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>>
>>> Cc: core-libs-dev at openjdk.java.net 
>>> <mailto:core-libs-dev at openjdk.java.net>, build-dev 
>>> <build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>>
>>> Date: 30/08/2018 13:49
>>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>>> 
------------------------------------------------------------------------ 
>>>
>>>
>>>
>>>
>>> Andrew,
>>>
>>> If you want to make changes to the build system (files in make/*),
>>> please always include build-dev in the reviews.
>>>
>>> From a build point, this fix looks okay. My general preference is to
>>> fix shady code instead of disabling warnings, but in this case it's in
>>> two libraries that are either external or moribound, so if the
>>> maintainer's of the respective libraries want to avoid code changes, I
>>> accept that.
>>>
>>> /Magnus
>>>
>>>
>>> On 2018-08-30 14:18, Andrew Leonard wrote:
>>> > Hi Brian,
>>> > Thanks for taking a look at this, I have just done a rebuild with 
>>> a new
>>> > patch with appropriate gcc disable warnings for these libraries:
>>> > 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 

>>> <
http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/
>
>>> > This works fine, so if you think this is a more favourable 
>>> approach for
>>> > these libraries? i'd like to get this merged please.
>>> > Thanks
>>> > Andrew
>>> >
>>> > Andrew Leonard
>>> > Java Runtimes Development
>>> > IBM Hursley
>>> > IBM United Kingdom Ltd
>>> > Phone internal: 245913, external: 01962 815913
>>> > internet email: andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>
>>> >
>>> >
>>> >
>>> >
>>> > From:   Brian Burkhalter <brian.burkhalter at oracle.com 
>>> <mailto:brian.burkhalter at oracle.com>>
>>> > To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com 
>>> <mailto:andrew_m_leonard at uk.ibm.com>>
>>> > Cc: core-libs-dev at openjdk.java.net 
>>> <mailto:core-libs-dev at openjdk.java.net>
>>> > Date:   28/08/2018 15:52
>>> > Subject:        Re: RFR JDK-8209786: gcc 7.3 compiler errors on 
>>> zLinux
>>> >
>>> >
>>> >
>>> > Hi Andrew,
>>> >
>>> > It was suggested that it would be preferable to dial down the 
>>> compilation
>>> > settings for the fdlibm code rather than make a source code 
>>> change. Was
>>> > this investigated?
>>> >
>>> > Thanks,
>>> >
>>> > Brian
>>> >
>>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
>>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>>
>>> > wrote:
>>> >
>>> > We have discovered issues with gcc 7.3 on zLinux, combined with 
>>> OpenJDK's
>>> > default compiler options has highlighted a couple of native code 
>>> issues,
>>> > with undefined behaviours:
>>> >   - validating loop test array bounds
>>> >   - left shifts of negative values
>>> > I have created bug 
https://bugs.openjdk.java.net/browse/JDK-8209786

>>> > and attached the webrev fix here:
>>> > 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 

>>> <
http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/
>
>>> >
>>> > This has already been discussed and refined on the "s390x-port-dev"
>>> > maillist
>>> > and as it was pointed out, it should have been posted here...
>>> >
>>> > I'd like to request a sponsor for this fix please?
>>> >
>>> >
>>> >
>>> >
>>> > Unless stated otherwise above:
>>> > IBM United Kingdom Limited - Registered in England and Wales with 
>>> number
>>> > 741598.
>>> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>>> PO6 3AU
>>>
>>>
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with 
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>>> PO6 3AU
>>






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From magnus.ihse.bursie at oracle.com  Fri Aug 31 09:28:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 31 Aug 2018 11:28:23 +0200
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <OF2A92E894.CE374AFC-ON802582FA.00317DC3-802582FA.0032C01A@notes.na.collabserv.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
 <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
 <5B887D89.9070201@oracle.com>
 <6163c668-1584-bc17-de92-26e518830cdf@oracle.com>
 <OF2A92E894.CE374AFC-ON802582FA.00317DC3-802582FA.0032C01A@notes.na.collabserv.com>
Message-ID: <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com>



On 2018-08-31 11:14, Andrew Leonard wrote:
> Hi,
> So there seems to be varying opinion here, taking the 2D view point 
> since it is going to be maintained, the opinion seems to be more with 
> the fix (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>). This 
> would be my personal preference also, but previous comments seemed to 
> prefer compiler options.
>
> Looking at each error:
> - */libfdlibm/k_rem_pio2.c* : This is a simple "for" loop bound check, 
> which with good programming practice should really have been there to 
> prevent ArrayOutOfBounds.. or native overwrites.. Simple fix.
> - *libmlib_image/mlib_ImageLookUp_Bit.c* : This is -ve bit shifting 
> which is spec undefined, which in theory could mean it breaks in the 
> future if we upgrade/change compiler... However, this is complex code, 
> we need to be very sure the new fix is "correct", myself and my 
> colleague here have examined it closely and are happy, but i'd 
> appreciate your in-depth analysis please. 
It looks good. The intention of the old code has clearly been to have an 
32 or 64-bit wide all-1s bitmask, and this is what your fix delivers as 
well.

>
>
> Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or 
> "DisableWarnings" ?

Note that this decision can be different for the two libraries. I'd 
argue that the maintainer of each library decides. And if so, it seems 
to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image.

/Magnus


>
>
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leonard at uk.ibm.com
>
>
>
>
> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> To: Philip Race <philip.race at oracle.com>, Brian Burkhalter 
> <brian.burkhalter at oracle.com>
> Cc: 2d-dev <2d-dev at openjdk.java.net>, build-dev 
> <build-dev at openjdk.java.net>, Andrew Leonard 
> <andrew_m_leonard at uk.ibm.com>, core-libs-dev 
> <core-libs-dev at openjdk.java.net>
> Date: 31/08/2018 09:27
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
> on zLinux
> ------------------------------------------------------------------------
>
>
>
> On 2018-08-31 01:28, Philip Race wrote:
> > Some day, I'd like to replace a lot of medialib functionality with
> > something
> > like the proposed Vector API. But that is far enough away that
> > medialib needs
> > to be maintained, and unlike a previous discussion about a similar
> > issue in
> > the JPEG library, we are on the hook for maintaining medialib.
> > So if there is an actual logic error in medialib, I'd prefer to fix it.
> > If the issue is a false positive, I'd be OK to disable the warning,
> > but wrapped
> > in a platform-specific manner. So is it a real error here ?
>
> Gcc is emitting a warning due to shifting of negative values, which is
> deemed undefined behavior by the spec.
>
> Is this a real error? Well. Undefined behavior is no good. It can work
> for now and then suddenly start breaking.
>
> The originally suggested code change
> (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00 
> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00>) seems
> reasonable to me. It is at the very least much clearer what the
> intention is. And it's conformant with the spec.
>
> So I'd advocate using that fix, if you want to continue supporting the
> library.
>
> /Magnus
>
>
>
>
> >
> > -phil.
> >
> > On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
> >> Hi Andrew,
> >>
> >> As noted in the issue comments, the fdlibm C code is obsolescent and
> >> eventually to be superseded by equivalent Java implementations. As
> >> for the mediaLib code being moribund I cannot speak but am copying
> >> 2d-dev which owns java.desktop.
> >>
> >> Thanks,
> >>
> >> Brian
> >>
> >> On Aug 30, 2018, at 6:03 AM, Andrew Leonard
> >> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>>
> >> wrote:
> >>
> >>> Thanks Magnus,
> >>> Yes, these libraries are moribound it seems, hence their preference
> >>> for compile options..
> >>> Cheers
> >>> Andrew
> >>>
> >>> Andrew Leonard
> >>> Java Runtimes Development
> >>> IBM Hursley
> >>> IBM United Kingdom Ltd
> >>> Phone internal: 245913, external: 01962 815913
> >>> internet email: andrew_m_leonard at uk.ibm.com
> >>> <mailto:andrew_m_leonard at uk.ibm.com>
> >>>
> >>>
> >>>
> >>>
> >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
> >>> <mailto:magnus.ihse.bursie at oracle.com>>
> >>> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com
> >>> <mailto:andrew_m_leonard at uk.ibm.com>>, Brian Burkhalter
> >>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>>
> >>> Cc: core-libs-dev at openjdk.java.net
> >>> <mailto:core-libs-dev at openjdk.java.net>, build-dev
> >>> <build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>>
> >>> Date: 30/08/2018 13:49
> >>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
> >>> 
> ------------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>> Andrew,
> >>>
> >>> If you want to make changes to the build system (files in make/*),
> >>> please always include build-dev in the reviews.
> >>>
> >>> From a build point, this fix looks okay. My general preference is to
> >>> fix shady code instead of disabling warnings, but in this case it's in
> >>> two libraries that are either external or moribound, so if the
> >>> maintainer's of the respective libraries want to avoid code changes, I
> >>> accept that.
> >>>
> >>> /Magnus
> >>>
> >>>
> >>> On 2018-08-30 14:18, Andrew Leonard wrote:
> >>> > Hi Brian,
> >>> > Thanks for taking a look at this, I have just done a rebuild with
> >>> a new
> >>> > patch with appropriate gcc disable warnings for these libraries:
> >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/>
> >>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/>
> >>> > This works fine, so if you think this is a more favourable
> >>> approach for
> >>> > these libraries? i'd like to get this merged please.
> >>> > Thanks
> >>> > Andrew
> >>> >
> >>> > Andrew Leonard
> >>> > Java Runtimes Development
> >>> > IBM Hursley
> >>> > IBM United Kingdom Ltd
> >>> > Phone internal: 245913, external: 01962 815913
> >>> > internet email: andrew_m_leonard at uk.ibm.com
> >>> <mailto:andrew_m_leonard at uk.ibm.com>
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > From:?? Brian Burkhalter <brian.burkhalter at oracle.com
> >>> <mailto:brian.burkhalter at oracle.com>>
> >>> > To:???? Andrew Leonard <andrew_m_leonard at uk.ibm.com
> >>> <mailto:andrew_m_leonard at uk.ibm.com>>
> >>> > Cc: core-libs-dev at openjdk.java.net
> >>> <mailto:core-libs-dev at openjdk.java.net>
> >>> > Date:?? 28/08/2018 15:52
> >>> > Subject:??????? Re: RFR JDK-8209786: gcc 7.3 compiler errors on
> >>> zLinux
> >>> >
> >>> >
> >>> >
> >>> > Hi Andrew,
> >>> >
> >>> > It was suggested that it would be preferable to dial down the
> >>> compilation
> >>> > settings for the fdlibm code rather than make a source code
> >>> change. Was
> >>> > this investigated?
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Brian
> >>> >
> >>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard
> >>> <andrew_m_leonard at uk.ibm.com <mailto:andrew_m_leonard at uk.ibm.com>>
> >>> > wrote:
> >>> >
> >>> > We have discovered issues with gcc 7.3 on zLinux, combined with
> >>> OpenJDK's
> >>> > default compiler options has highlighted a couple of native code
> >>> issues,
> >>> > with undefined behaviours:
> >>> >?? - validating loop test array bounds
> >>> >?? - left shifts of negative values
> >>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> >>> > and attached the webrev fix here:
> >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>
> >>> <http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>
> >>> >
> >>> > This has already been discussed and refined on the "s390x-port-dev"
> >>> > maillist
> >>> > and as it was pointed out, it should have been posted here...
> >>> >
> >>> > I'd like to request a sponsor for this fix please?
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > Unless stated otherwise above:
> >>> > IBM United Kingdom Limited - Registered in England and Wales with
> >>> number
> >>> > 741598.
> >>> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> >>> PO6 3AU
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Unless stated otherwise above:
> >>> IBM United Kingdom Limited - Registered in England and Wales with
> >>> number 741598.
> >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> >>> PO6 3AU
> >>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From matthias.baesken at sap.com  Fri Aug 31 12:52:34 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 31 Aug 2018 12:52:34 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
 <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
 <eb76647f7bff4042a692b39190179034@sap.com>
 <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>
Message-ID: <fb1f761a8cfc4ae9970f5431062423dd@sap.com>

Hi Max :

> 
> - No need to "import java.security.Security".

Sure  I can remove this, it is a leftover.

> - In the updated read() method, I think there is no need to use an "int offset"
> parameter. "int lineNumber" is enough and you can modify it and return it
> without a new local variable.
>

Currently we need it in Manifest.java  public void read(InputStream is) throws IOException { ... }

> In fact, I have a small concern on the hardcoded file name here, because
> when verifying a signed jar, the META-INF/X.SF file is also parsed into a
> Manifest object and if it's invalid similar exceptions will be thrown. I don't
> have a nice solution now.

Then lets just say   <jarfile>:<line-number>   (e.g.  test.jar:10 )

 Or ( to mention that it is about a manifest  from the jar )

<jarfile>:manifest-line <line-number>   (e.g.  test.jar:manifest-line 10 )


Best regards, Matthias



> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Freitag, 31. August 2018 04:32
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> Some more comments:
> 
> Attributes.java
> 
> - No need to "import java.security.Security".
> 
> - In the updated read() method, I think there is no need to use an "int offset"
> parameter. "int lineNumber" is enough and you can modify it and return it
> without a new local variable.
> 
> - I feel like calling Attributes::getErrorPosition from Manifest a little strange.
> Maybe it's better to define the method in Manifest and call it from
> Attributes. First, I think putting the method in a higher level object makes
> more sense. Second, the position is for the whole Manifest and not an
> Attributes section (I mean the line number is counted from the first line of
> the manifest).
> 
> > On Aug 30, 2018, at 10:50 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> >
> >
> > Hi  Max, probably   we should add  the  info about the MANIFEST.MF  , for
> example :
> > change  getErrorPosition  to
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s
> hare/classes/java/util/jar/Attributes.java.udiff.html
> >
> >
> >    static String getErrorPosition(String filename, final int lineNumber) {
> >        if (filename == null || !jarPathInExceptionText) {
> >            return "META-INF/MANIFEST.MF  line:" + lineNumber;
> >       }
> >
> >       final File file = new File(filename);
> >        return AccessController.doPrivileged(new PrivilegedAction<String>() {
> >            public String run() {
> >                return file.getAbsolutePath() + "!META-INF/MANIFEST.MF  line:" +
> lineNumber;
> 
> I prefer "file:line" which is more compact and more commonly used.
> 
> In fact, I have a small concern on the hardcoded file name here, because
> when verifying a signed jar, the META-INF/X.SF file is also parsed into a
> Manifest object and if it's invalid similar exceptions will be thrown. I don't
> have a nice solution now. if we want to show the .SF name also, we will need
> a public API because SignatureFileVerifier.java is inside sun.security.util.
> Something like Manifest(InputStream,jarName,entryName)?
> 
> Sorry for making this complicated.
> 
> Thanks
> Max
> 
> >         }
> >   .....
> >
> >
> > Best regards, Matthias
> >
> >
> >
> >> -----Original Message-----
> >> From: Weijun Wang <weijun.wang at oracle.com>
> >> Sent: Donnerstag, 30. August 2018 16:04
> >> To: Baesken, Matthias <matthias.baesken at sap.com>
> >> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
> >> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
> >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> >> parsing of jar archives
> >>
> >>
> >>
> >>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias
> >> <matthias.baesken at sap.com> wrote:
> >>>
> >>>> - What will the output look like? Is it "/tmp/x.jar:100"?
> >>>>
> >>>
> >>> Yes it look like this :
> >>>
> >>> line too long (/testdata/jars/file_with_long_line_1.jar:2)
> >>
> >> Is this a little misleading? I think you mean
> >>
> >>   /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2
> >>
> >> Thanks
> >> Max


From weijun.wang at oracle.com  Fri Aug 31 13:53:01 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 31 Aug 2018 21:53:01 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <fb1f761a8cfc4ae9970f5431062423dd@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com>
 <34b096660ca44a4cb3f674198cd51d35@sap.com>
 <dedd88ec-8b74-7c05-22aa-f4e211b7209b@oracle.com>
 <036f88e423b743bbb68c73e2a59486d4@sap.com>
 <e9179c11-50c0-7bb4-7096-6f93abe0f5a5@oracle.com>
 <b97fb6c33fc24ac6b2424456a33ae38e@sap.com>
 <ac3065ad5ab24c549019de2778d80fb9@sap.com>
 <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com>
 <6cfa4b0266de4fdf85d6c959c450043c@sap.com>
 <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com>
 <60acb2950d9147e5adc8e246de7d7b08@sap.com>
 <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com>
 <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com>
 <252b3b00f4e94b8796256675ce2571b1@sap.com>
 <9bb8b30850aa48e493a15d48cfd79efa@sap.com>
 <dec9ee71-6391-ca65-de85-59a24e63e7e1@oracle.com>
 <f0e42794-e830-0b1d-cd3d-ff430d92d216@oracle.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <D8E2B139-C66C-4664-ACB7-6E2BFFD2773D@oracle.com>
 <e76f3a3577af4797b858b16af7715e51@sap.com>
 <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com>
 <eb76647f7bff4042a692b39190179034@sap.com>
 <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com>
 <fb1f761a8cfc4ae9970f5431062423dd@sap.com>
Message-ID: <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@oracle.com>



> On Aug 31, 2018, at 8:52 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Max :
> 
>> 
>> - No need to "import java.security.Security".
> 
> Sure  I can remove this, it is a leftover.
> 
>> - In the updated read() method, I think there is no need to use an "int offset"
>> parameter. "int lineNumber" is enough and you can modify it and return it
>> without a new local variable.
>> 
> 
> Currently we need it in Manifest.java  public void read(InputStream is) throws IOException { ... }

I was talking about the name of the parameter. You can simply use

    int read(Manifest.FastInputStream is, byte[] lbuf, String filename, int lineNumber)

and there is no need to reassign it with "int lineNumber = offset" anymore.

> 
>> In fact, I have a small concern on the hardcoded file name here, because
>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a
>> Manifest object and if it's invalid similar exceptions will be thrown. I don't
>> have a nice solution now.
> 
> Then lets just say   <jarfile>:<line-number>   (e.g.  test.jar:10 )
> 
> Or ( to mention that it is about a manifest  from the jar )
> 
> <jarfile>:manifest-line <line-number>   (e.g.  test.jar:manifest-line 10 )

How about you pass in the full name ("/path/to/file.jar!META-INF/MANIFEST.MF") to "new Manifest(stream,name)" directly?

So the name will be constructed in JarFile.java (after checking for jarPathInExceptionText). The getErrorPosition method simply concat the name (if not null) and the line number. Thus the exception thrown from parsing X.SF simply will not include any file info. If we want it we can enhance later.

Thanks
Max

> 
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Weijun Wang <weijun.wang at oracle.com>
>> Sent: Freitag, 31. August 2018 04:32
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>> parsing of jar archives
>> 
>> Some more comments:
>> 
>> Attributes.java
>> 
>> - No need to "import java.security.Security".
>> 
>> - In the updated read() method, I think there is no need to use an "int offset"
>> parameter. "int lineNumber" is enough and you can modify it and return it
>> without a new local variable.
>> 
>> - I feel like calling Attributes::getErrorPosition from Manifest a little strange.
>> Maybe it's better to define the method in Manifest and call it from
>> Attributes. First, I think putting the method in a higher level object makes
>> more sense. Second, the position is for the whole Manifest and not an
>> Attributes section (I mean the line number is counted from the first line of
>> the manifest).
>> 
>>> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> 
>>> 
>>> Hi  Max, probably   we should add  the  info about the MANIFEST.MF  , for
>> example :
>>> change  getErrorPosition  to
>>> 
>>> 
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s
>> hare/classes/java/util/jar/Attributes.java.udiff.html
>>> 
>>> 
>>>   static String getErrorPosition(String filename, final int lineNumber) {
>>>       if (filename == null || !jarPathInExceptionText) {
>>>           return "META-INF/MANIFEST.MF  line:" + lineNumber;
>>>      }
>>> 
>>>      final File file = new File(filename);
>>>       return AccessController.doPrivileged(new PrivilegedAction<String>() {
>>>           public String run() {
>>>               return file.getAbsolutePath() + "!META-INF/MANIFEST.MF  line:" +
>> lineNumber;
>> 
>> I prefer "file:line" which is more compact and more commonly used.
>> 
>> In fact, I have a small concern on the hardcoded file name here, because
>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a
>> Manifest object and if it's invalid similar exceptions will be thrown. I don't
>> have a nice solution now. if we want to show the .SF name also, we will need
>> a public API because SignatureFileVerifier.java is inside sun.security.util.
>> Something like Manifest(InputStream,jarName,entryName)?
>> 
>> Sorry for making this complicated.
>> 
>> Thanks
>> Max
>> 
>>>        }
>>>  .....
>>> 
>>> 
>>> Best regards, Matthias
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Weijun Wang <weijun.wang at oracle.com>
>>>> Sent: Donnerstag, 30. August 2018 16:04
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>> Cc: Alan Bateman <Alan.Bateman at oracle.com>; Sean Mullan
>>>> <sean.mullan at oracle.com>; Chris Hegarty <chris.hegarty at oracle.com>;
>>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
>>>> parsing of jar archives
>>>> 
>>>> 
>>>> 
>>>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias
>>>> <matthias.baesken at sap.com> wrote:
>>>>> 
>>>>>> - What will the output look like? Is it "/tmp/x.jar:100"?
>>>>>> 
>>>>> 
>>>>> Yes it look like this :
>>>>> 
>>>>> line too long (/testdata/jars/file_with_long_line_1.jar:2)
>>>> 
>>>> Is this a little misleading? I think you mean
>>>> 
>>>>  /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2
>>>> 
>>>> Thanks
>>>> Max
> 


From maurizio.cimadamore at oracle.com  Fri Aug 31 13:59:30 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 31 Aug 2018 14:59:30 +0100
Subject: RFR 8210226: Add support for multiple project folders to idea.sh
In-Reply-To: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
References: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
Message-ID: <b674e87b-93c1-13c9-9b50-630564879710@oracle.com>

Thanks for the reviews; once again, when doing some more testing I 
discovered some issues which had to do with coexistence with the 
intellij jtreg plugin.

The bottom of the issue is that certain IDE owned ant variable (such as 
$ModuleFileDir$) are only set when clicking on certain IDE actions, but 
not on other. This leads to a very messy behavior, where certain times 
the IDE will fail to build the project if the build is triggered 
implicitly? (e.g. upon running a jtreg test from the IDE).

I now got rid of references to such variables and replaced it with 
references to a new IDEA_DIR template variable, whose addition in the 
idea.sh script is straighforward.

To make sure that I got all bases covered, I tested in the following fashion

1) create a project for java.base and jdk.compiler module in the root folder
- verify that source files belonging to either of the above modules can 
be opened inside the IDE
- verify that jtreg tests can be run from the IDE (and that it triggers 
'make images' correctly)
- verify that the build/rebuild buttons of the IDE also work
- check consistency of IDE setting by inspecting various menus (e.g. 
Project structure and Project settings)

2) create a project for java.desktop in a folder called desktop (e.g. 
using -o desktop), then check again:
- verify that source files belonging to the java.desktop module can be 
opened inside the IDE
- verify that jtreg tests can be run from the IDE (and that it triggers 
'make images' correctly)
- verify that the build/rebuild buttons of the IDE also work
- check consistency of IDE setting by inspecting various menus (e.g. 
Project structure and Project settings)


This all worked as expected.

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210226_v2/


Sorry for the review churn!

Maurizio





On 30/08/18 16:12, Maurizio Cimadamore wrote:
> Hi,
> this patch adds proper support for -o option to the idea.sh script, 
> which allows to place the .idea folder under any given output folder 
> (not necessarily the JDK root).
>
> To be able to do this, I had to revampo the logic for template 
> substitution in idea.sh, as it was growing too brittle. I now have a 
> much more declarative logic, where replacements can be added by 
> calling the add_replacement function. This allows to replace a lot of 
> the previous code with very simple and self-explanatory calls to that 
> routine.
>
> This piece was necessary, as we needed to replace a lot of references 
> to the idea variable $PROJECT_DIR with the new template variable 
> ###ROOT_DIR### (otherwise the project is ill-formed, since 
> $PROJECT_DIR merely points at the folder containing the .idea project 
> folder).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210226/
>
> Cheers
> Maurizio
>


From brian.burkhalter at oracle.com  Fri Aug 31 14:43:29 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 Aug 2018 07:43:29 -0700
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com>
References: <OF89049192.80E8827F-ON802582F7.004E1074-802582F7.004E9954@notes.na.collabserv.com>
 <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com>
 <OF35142F2B.F9871854-ON802582F9.0043668E-802582F9.00439BEC@notes.na.collabserv.com>
 <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com>
 <OF39DBF7E5.6FDDB6E0-ON802582F9.004793A7-802582F9.0047B119@notes.na.collabserv.com>
 <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com>
 <5B887D89.9070201@oracle.com>
 <6163c668-1584-bc17-de92-26e518830cdf@oracle.com>
 <OF2A92E894.CE374AFC-ON802582FA.00317DC3-802582FA.0032C01A@notes.na.collabserv.com>
 <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com>
Message-ID: <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com>


On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

>> Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ?
> 
> Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image.

I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe Darcy?s comment in the issue (he owns fdlibm), and source code change for mediaLib as Phil indicated in e-mail.

Thanks,

Brian

From erik.joelsson at oracle.com  Fri Aug 31 16:23:38 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Aug 2018 09:23:38 -0700
Subject: RFR 8210226: Add support for multiple project folders to idea.sh
In-Reply-To: <b674e87b-93c1-13c9-9b50-630564879710@oracle.com>
References: <31d9c792-b743-5f05-231d-4de2eed8c4d8@oracle.com>
 <b674e87b-93c1-13c9-9b50-630564879710@oracle.com>
Message-ID: <1ec509f5-0037-7944-a506-a7f190559991@oracle.com>

Looks ok to me (and same caveat as Magnus).

/Erik


On 2018-08-31 06:59, Maurizio Cimadamore wrote:
> Thanks for the reviews; once again, when doing some more testing I 
> discovered some issues which had to do with coexistence with the 
> intellij jtreg plugin.
>
> The bottom of the issue is that certain IDE owned ant variable (such 
> as $ModuleFileDir$) are only set when clicking on certain IDE actions, 
> but not on other. This leads to a very messy behavior, where certain 
> times the IDE will fail to build the project if the build is triggered 
> implicitly? (e.g. upon running a jtreg test from the IDE).
>
> I now got rid of references to such variables and replaced it with 
> references to a new IDEA_DIR template variable, whose addition in the 
> idea.sh script is straighforward.
>
> To make sure that I got all bases covered, I tested in the following 
> fashion
>
> 1) create a project for java.base and jdk.compiler module in the root 
> folder
> - verify that source files belonging to either of the above modules 
> can be opened inside the IDE
> - verify that jtreg tests can be run from the IDE (and that it 
> triggers 'make images' correctly)
> - verify that the build/rebuild buttons of the IDE also work
> - check consistency of IDE setting by inspecting various menus (e.g. 
> Project structure and Project settings)
>
> 2) create a project for java.desktop in a folder called desktop (e.g. 
> using -o desktop), then check again:
> - verify that source files belonging to the java.desktop module can be 
> opened inside the IDE
> - verify that jtreg tests can be run from the IDE (and that it 
> triggers 'make images' correctly)
> - verify that the build/rebuild buttons of the IDE also work
> - check consistency of IDE setting by inspecting various menus (e.g. 
> Project structure and Project settings)
>
>
> This all worked as expected.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210226_v2/
>
>
> Sorry for the review churn!
>
> Maurizio
>
>
>
>
>
> On 30/08/18 16:12, Maurizio Cimadamore wrote:
>> Hi,
>> this patch adds proper support for -o option to the idea.sh script, 
>> which allows to place the .idea folder under any given output folder 
>> (not necessarily the JDK root).
>>
>> To be able to do this, I had to revampo the logic for template 
>> substitution in idea.sh, as it was growing too brittle. I now have a 
>> much more declarative logic, where replacements can be added by 
>> calling the add_replacement function. This allows to replace a lot of 
>> the previous code with very simple and self-explanatory calls to that 
>> routine.
>>
>> This piece was necessary, as we needed to replace a lot of references 
>> to the idea variable $PROJECT_DIR with the new template variable 
>> ###ROOT_DIR### (otherwise the project is ill-formed, since 
>> $PROJECT_DIR merely points at the folder containing the .idea project 
>> folder).
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8210226/
>>
>> Cheers
>> Maurizio
>>
>


From igor.ignatyev at oracle.com  Fri Aug 31 18:42:25 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 31 Aug 2018 11:42:25 -0700
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
Message-ID: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>

Alan, Chris,

thanks for looking at it, I went w/ the alternative suggested by Chris. that required a sprinkle of doPrivileged in the testlibrary, but now Sockets/policy.* files grant the minimal required permissions to the test code.
the incremental webrev can found here[1], please let me know if you need the whole webrev.

[1] http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html

Thanks,
-- Igor


> On Aug 30, 2018, at 3:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> 
>> On 30 Aug 2018, at 08:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 28/08/2018 17:50, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>>> 698 lines changed: 114 ins; 240 del; 344 mod
>>> Hi all,
>>> 
>>> could you please review this clean up of jdk testlibrary?
>>> the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion.
>>> 
>>> testing: changed tests + :jdk_desktop test group
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210039
>>> 
>> The updates to the Sockets policy file suggests using this jdk.test.lib.Platform/OSVersion requires permissions that the test infrastructure needs, not the test. It's not wrong but it's always a concern when tests running with a security manager are granted non-obvious permissions.
> 
> The uses of test libraries with security manager is a little
> cumbersome, and usually ends up with the test code being
> granted more permissions than is necessary. I share Alan?s
> concern.
> 
> Another alternative, that we used in other areas, is to grant
> the test library only minimal permissions, separate to the
> actual test code. For example:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24 <http://hg.openjdk.java.net/jdk/jdk/file/9183040e34d8/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24>
> 
> -Chris.