From ivan.gerasimov at oracle.com  Sat Sep  1 00:17:33 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 31 Aug 2018 17:17:33 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject NaN
Message-ID: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>

Hello!

The javadoc for CharsetDecoder [1] states that an exception is thrown 
when a non-positive number is passed in as an argument.

However we only reject negative or zero numbers, but not NaN.

And likewise for CharsetEncoder.

Would you please help review a trivial fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/

Thanks in advance!

[1] 
https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float)

-- 
With kind regards,
Ivan Gerasimov


From ecki at zusammenkunft.net  Sat Sep  1 01:22:10 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 1 Sep 2018 01:22:10 +0000
Subject: Are TimeZone instances guaranteed to be thread-safe
Message-ID: <DB7PR08MB33072387D381AA4B76388407FF0E0@DB7PR08MB3307.eurprd08.prod.outlook.com>

Hello,

I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well),

Since TimeZone is used together with Calendar it might be natural for developers to know.

Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this ?fast? implementation.

[ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ]

I can imagine naming it GMT vs. UTC might also be a nice bike shed.

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

From ecki at zusammenkunft.net  Sat Sep  1 01:58:19 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 1 Sep 2018 01:58:19 +0000
Subject: Are TimeZone instances guaranteed to be thread-safe
In-Reply-To: <DB7PR08MB33072387D381AA4B76388407FF0E0@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <DB7PR08MB33072387D381AA4B76388407FF0E0@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <DB7PR08MB33070AD860395739AF59FAD0FF0E0@DB7PR08MB3307.eurprd08.prod.outlook.com>

Ah BTW, there is a TimeZone.getTimezone(ZoneOffset.UTC) construct which can be used. The ZoneId is also immutable, but that construct does say nothing about TimeZone instance.

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

________________________________
Von: Bernd Eckenfels <ecki at zusammenkunft.net>
Gesendet: Samstag, September 1, 2018 3:22 AM
An: core-libs-dev at openjdk.java.net
Betreff: Are TimeZone instances guaranteed to be thread-safe

Hello,

I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well),

Since TimeZone is used together with Calendar it might be natural for developers to know.

Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this ?fast? implementation.

[ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ]

I can imagine naming it GMT vs. UTC might also be a nice bike shed.

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

From xueming.shen at oracle.com  Sun Sep  2 18:14:36 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 02 Sep 2018 11:14:36 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject
 NaN
In-Reply-To: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
Message-ID: <5B8C288C.2090406@oracle.com>

+1

On 8/31/18, 5:17 PM, Ivan Gerasimov wrote:
> Hello!
>
> The javadoc for CharsetDecoder [1] states that an exception is thrown 
> when a non-positive number is passed in as an argument.
>
> However we only reject negative or zero numbers, but not NaN.
>
> And likewise for CharsetEncoder.
>
> Would you please help review a trivial fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
> WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/
>
> Thanks in advance!
>
> [1] 
> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float)
>


From stuart.marks at oracle.com  Sun Sep  2 21:45:07 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sun, 2 Sep 2018 14:45:07 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <5B8C288C.2090406@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <5B8C288C.2090406@oracle.com>
Message-ID: <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>

Yes, the fix itself looks fine. Quite subtle, good catch.

But should this have a regression test? I can imagine somebody coming along 
later and "simplifying" (!(... > ...)) to (... <= ...) which would reintroduce 
the bug.

s'marks

On 9/2/18 11:14 AM, Xueming Shen wrote:
> +1
> 
> On 8/31/18, 5:17 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The javadoc for CharsetDecoder [1] states that an exception is thrown when a 
>> non-positive number is passed in as an argument.
>>
>> However we only reject negative or zero numbers, but not NaN.
>>
>> And likewise for CharsetEncoder.
>>
>> Would you please help review a trivial fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/
>>
>> Thanks in advance!
>>
>> [1] 
>> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float) 
>>
>>
> 

From ivan.gerasimov at oracle.com  Mon Sep  3 04:54:47 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 2 Sep 2018 21:54:47 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <5B8C288C.2090406@oracle.com>
 <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>
Message-ID: <7772e7c9-61f7-73ff-5cde-ec50c907bb85@oracle.com>

Thanks Sherman and Stuart for the review!

On 9/2/18 2:45 PM, Stuart Marks wrote:
> Yes, the fix itself looks fine. Quite subtle, good catch.
>
> But should this have a regression test? I can imagine somebody coming 
> along later and "simplifying" (!(... > ...)) to (... <= ...) which 
> would reintroduce the bug.
>
Yes, there is a regression test added:
http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/test/jdk/java/nio/charset/CharsetDecoder/NaNinCtor.java.html

With kind regards,
Ivan

> s'marks
>
> On 9/2/18 11:14 AM, Xueming Shen wrote:
>> +1
>>
>> On 8/31/18, 5:17 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> The javadoc for CharsetDecoder [1] states that an exception is 
>>> thrown when a non-positive number is passed in as an argument.
>>>
>>> However we only reject negative or zero numbers, but not NaN.
>>>
>>> And likewise for CharsetEncoder.
>>>
>>> Would you please help review a trivial fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/
>>>
>>> Thanks in advance!
>>>
>>> [1] 
>>> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float) 
>>>
>>>
>>
>

-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Mon Sep  3 10:57:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 3 Sep 2018 11:57:18 +0100
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <7772e7c9-61f7-73ff-5cde-ec50c907bb85@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <5B8C288C.2090406@oracle.com>
 <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>
 <7772e7c9-61f7-73ff-5cde-ec50c907bb85@oracle.com>
Message-ID: <effae057-b0fa-29d3-c4d8-d19d974086f3@oracle.com>

On 03/09/2018 05:54, Ivan Gerasimov wrote:
> Thanks Sherman and Stuart for the review!
>
> On 9/2/18 2:45 PM, Stuart Marks wrote:
>> Yes, the fix itself looks fine. Quite subtle, good catch.
>>
>> But should this have a regression test? I can imagine somebody coming 
>> along later and "simplifying" (!(... > ...)) to (... <= ...) which 
>> would reintroduce the bug.
>>
> Yes, there is a regression test added:
> http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/test/jdk/java/nio/charset/CharsetDecoder/NaNinCtor.java.html 
>
The update to Charset-X-Coder.java.template looks okay. The changes also 
CharsetEncoder so we'll need test coverage for that too.

-Alan

From maurizio.cimadamore at oracle.com  Mon Sep  3 12:39:19 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 3 Sep 2018 13:39:19 +0100
Subject: RFR 8210318: idea.sh script doesn't work on Mac
Message-ID: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>

Hi,
following the latest updates to the idea.sh script, Mac users reported 
issues - mostly having to do with usage of 'sed' - more specifically:

* sed -i option is not portable - it has different formats in Mac vs. 
Linux. This patch does without -i, by moving the replaced file onto a 
temporary file, then moving such file on top of the template file in a 
subsequent step. This should be more robust.

* sed doesn't like newlines in replaced text in Mac. I've thus omitted 
the newline from the SOURCE template - as that was mostly cosmetic.

Thanks for Michael McMahon to report (and figure out how to deal with) 
these issues, and to Alan Bateman for testing the patch.

I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location in the 
various run configuration.

Webrev:

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

Cheers
Maurizio


From matthias.baesken at sap.com  Mon Sep  3 14:19:40 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 3 Sep 2018 14:19:40 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@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>
 <fb1f761a8cfc4ae9970f5431062423dd@sap.com>
 <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@oracle.com>
Message-ID: <38f2e1d2cbe24387bf693ac55492cf68@sap.com>

Hi Max,  I

- moved getErrorPosition  method   to  Manifest.java
- in read() method,   removed "int offset"
- in  the exception message, I write now  " manifest of "  ...   (without mentioning a manifest name)

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/


Best regards, Matthias


> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Freitag, 31. August 2018 15:53
> 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 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 weijun.wang at oracle.com  Mon Sep  3 15:13:52 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 3 Sep 2018 23:13:52 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <38f2e1d2cbe24387bf693ac55492cf68@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>
 <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@oracle.com>
 <38f2e1d2cbe24387bf693ac55492cf68@sap.com>
Message-ID: <C3769928-A8BF-49D9-B032-CB671E749647@oracle.com>

Hi Matthias

The change looks fine. We can enhance the name if we want to support .SF parsing later.

Please revise your CSR and get it approved first.

Thanks
Max

> On Sep 3, 2018, at 10:19 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Max,  I
> 
> - moved getErrorPosition  method   to  Manifest.java
> - in read() method,   removed "int offset"
> - in  the exception message, I write now  " manifest of "  ...   (without mentioning a manifest name)
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/
> 
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Weijun Wang <weijun.wang at oracle.com>
>> Sent: Freitag, 31. August 2018 15:53
>> 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 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 martinrb at google.com  Mon Sep  3 15:31:40 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 3 Sep 2018 08:31:40 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <effae057-b0fa-29d3-c4d8-d19d974086f3@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <5B8C288C.2090406@oracle.com>
 <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>
 <7772e7c9-61f7-73ff-5cde-ec50c907bb85@oracle.com>
 <effae057-b0fa-29d3-c4d8-d19d974086f3@oracle.com>
Message-ID: <CA+kOe0-w1ihNiu=SD0XC+-R2KfSV4p+HA=-1euhqZdX7japqGg@mail.gmail.com>

Looks good to me.  I would add a call to

new MyDecoder(ascii, 0.5f, 1.5f)

to make sure all calls to the constructor don't throw (because e.g. for
ASCII we know the correct values are 1.0f).

(In any case it feels like an API design mistake - the Charset itself
should be the source of truth about charsPerByte)

On Mon, Sep 3, 2018 at 3:57 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 03/09/2018 05:54, Ivan Gerasimov wrote:
>
>> Thanks Sherman and Stuart for the review!
>>
>> On 9/2/18 2:45 PM, Stuart Marks wrote:
>>
>>> Yes, the fix itself looks fine. Quite subtle, good catch.
>>>
>>> But should this have a regression test? I can imagine somebody coming
>>> along later and "simplifying" (!(... > ...)) to (... <= ...) which would
>>> reintroduce the bug.
>>>
>>> Yes, there is a regression test added:
>> http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/test/
>> jdk/java/nio/charset/CharsetDecoder/NaNinCtor.java.html
>>
> The update to Charset-X-Coder.java.template looks okay. The changes also
> CharsetEncoder so we'll need test coverage for that too.
>
> -Alan
>

From Alan.Bateman at oracle.com  Mon Sep  3 17:05:58 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 3 Sep 2018 18:05:58 +0100
Subject: RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly
 while processing JAR file with "/" as a directory inside.
In-Reply-To: <5B8716A0.3000404@oracle.com>
References: <5B860066.3050201@oracle.com>
 <347effc7-149f-fcf7-77b3-59ad572634b0@oracle.com>
 <5B8716A0.3000404@oracle.com>
Message-ID: <117bf5b9-4ce9-c3ab-85d5-fb0f5037775f@oracle.com>



On 29/08/2018 22:56, Xueming Shen wrote:
>
> 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/
This approach looks good.

-Alan

From rob.mckenna at oracle.com  Mon Sep  3 21:48:04 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 3 Sep 2018 22:48:04 +0100
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
Message-ID: <20180903214804.GA2868@vimes>

Hi folks,

I'd like to get a re-review of this change:

https://bugs.openjdk.java.net/browse/JDK-8139965
http://cr.openjdk.java.net/~robm/8139965/webrev/

In case the original has gone stale:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042767.html

    -Rob


From amy.lu at oracle.com  Tue Sep  4 05:41:30 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Sep 2018 13:41:30 +0800
Subject: [12] RFR of JDK-8209832: Refactor
 jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
Message-ID: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>

test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh

Please review this patch to refactor above shell script test to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8209832
webrev: http://cr.openjdk.java.net/~amlu/8209832/webrev.00/

Thanks,
Amy

From xu.y.yin at oracle.com  Tue Sep  4 06:30:59 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 4 Sep 2018 14:30:59 +0800
Subject: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/
Message-ID: <ABDC8250-9ADB-4ACA-8041-EEF68AB96434@oracle.com>

Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ in OpenJDK, thanks

bug: https://bugs.openjdk.java.net/browse/JDK-8210339
webrev: http://cr.openjdk.java.net/~xyin/8210339/webrev.00/

Regards,
Chris

From Alan.Bateman at oracle.com  Tue Sep  4 07:14:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Sep 2018 08:14:18 +0100
Subject: [12] RFR of JDK-8209832: Refactor
 jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
In-Reply-To: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>
References: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>
Message-ID: <5be7b2cb-6c7c-b4e1-5fde-647d41f7da33@oracle.com>

On 04/09/2018 06:41, Amy Lu wrote:
> test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh
>
> Please review this patch to refactor above shell script test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8209832
> webrev: http://cr.openjdk.java.net/~amlu/8209832/webrev.00/
This looks okay. If you want, you can reduce the code in 
SetupGetCallerClass by replacing the initialization of dest with 
Path.of("bcp", "boot") as userDir is not needed. Also the nonExists 
check isn't needed either.

-Alan

From vyom.tewari at oracle.com  Tue Sep  4 07:39:12 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Tue, 4 Sep 2018 13:09:12 +0530
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
In-Reply-To: <20180903214804.GA2868@vimes>
References: <20180903214804.GA2868@vimes>
Message-ID: <4b154346-7a37-4db5-052f-354ccd5a4d6f@oracle.com>

Hi Rob,

Code change looks good to me.

Thanks,

Vyom


On Tuesday 04 September 2018 03:18 AM, Rob McKenna wrote:
> Hi folks,
>
> I'd like to get a re-review of this change:
>
> https://bugs.openjdk.java.net/browse/JDK-8139965
> http://cr.openjdk.java.net/~robm/8139965/webrev/
>
> In case the original has gone stale:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042767.html
>
>      -Rob
>


From chris.hegarty at oracle.com  Tue Sep  4 09:00:36 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 4 Sep 2018 10:00:36 +0100
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
In-Reply-To: <20180903214804.GA2868@vimes>
References: <20180903214804.GA2868@vimes>
Message-ID: <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com>

Rob,

> On 3 Sep 2018, at 22:48, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> Hi folks,
> 
> I'd like to get a re-review of this change:
> 
> https://bugs.openjdk.java.net/browse/JDK-8139965 <https://bugs.openjdk.java.net/browse/JDK-8139965>

This issue is closed as `will not fix`. I presume you will re-open it before pushing.

> http://cr.openjdk.java.net/~robm/8139965/webrev/ <http://cr.openjdk.java.net/~robm/8139965/webrev/>


43     private boolean completed;
Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted )

LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it?

Please check the indentation of LdapRequest.java L103 ( in
the new file ). It appears, in the webrev, that the trailing `}` is
not lined up.

The indentation doesn?t look right here either.
 624             if (nparent) {
 625                 LdapRequest ldr = pendingRequests;
 626                 while (ldr != null) {
 627                     ldr.close();
 628                         ldr = ldr.next;
 629                     }
 630                 }
 631             }

-Chris


From daniel.fuchs at oracle.com  Tue Sep  4 09:22:44 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 4 Sep 2018 10:22:44 +0100
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
In-Reply-To: <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com>
References: <20180903214804.GA2868@vimes>
 <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com>
Message-ID: <b95ebc4c-ee1d-dd11-34e8-493f71d416c4@oracle.com>

Hi Rob,

I concur with Chris.
completed needs to be volatile and close() needs to
set a flag and use offer like cancel().

The condition for testing for closed then becomes
that the flag is set and the queue is empty or has EOF
as its head.

Is there any way this could be tested by a regression
test?

best regards,

-- daniel

On 04/09/2018 10:00, Chris Hegarty wrote:
> Rob,
> 
>> On 3 Sep 2018, at 22:48, Rob McKenna <rob.mckenna at oracle.com> wrote:
>>
>> Hi folks,
>>
>> I'd like to get a re-review of this change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8139965 <https://bugs.openjdk.java.net/browse/JDK-8139965>
> 
> This issue is closed as `will not fix`. I presume you will re-open it before pushing.
> 
>> http://cr.openjdk.java.net/~robm/8139965/webrev/ <http://cr.openjdk.java.net/~robm/8139965/webrev/>
> 
> 
> 43     private boolean completed;
> Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted )
> 
> LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it?
> 
> Please check the indentation of LdapRequest.java L103 ( in
> the new file ). It appears, in the webrev, that the trailing `}` is
> not lined up.
> 
> The indentation doesn?t look right here either.
>   624             if (nparent) {
>   625                 LdapRequest ldr = pendingRequests;
>   626                 while (ldr != null) {
>   627                     ldr.close();
>   628                         ldr = ldr.next;
>   629                     }
>   630                 }
>   631             }
> 
> -Chris
> 


From amy.lu at oracle.com  Tue Sep  4 09:26:12 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Sep 2018 17:26:12 +0800
Subject: [12] RFR of JDK-8209832: Refactor
 jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
In-Reply-To: <5be7b2cb-6c7c-b4e1-5fde-647d41f7da33@oracle.com>
References: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>
 <5be7b2cb-6c7c-b4e1-5fde-647d41f7da33@oracle.com>
Message-ID: <3031698c-513c-182b-b7c7-82d102feb52d@oracle.com>

On 2018/9/4 3:14 PM, Alan Bateman wrote:
> On 04/09/2018 06:41, Amy Lu wrote:
>> test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh
>>
>> Please review this patch to refactor above shell script test to java.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209832
>> webrev: http://cr.openjdk.java.net/~amlu/8209832/webrev.00/
> This looks okay. If you want, you can reduce the code in 
> SetupGetCallerClass by replacing the initialization of dest with 
> Path.of("bcp", "boot") as userDir is not needed. Also the nonExists 
> check isn't needed either.
>
> -Alan

Thank you Alan!

I updated SetupGetCallerClass:
http://cr.openjdk.java.net/~amlu/8209832/webrev.01/

Thanks,
Amy

From amy.lu at oracle.com  Tue Sep  4 09:46:19 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Sep 2018 17:46:19 +0800
Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java
 back to tier1
Message-ID: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com>

test/jdk/java/util/Arrays/TimSortStackSize2.java

This test was demoted to tier2 due to JDK-8199265 (test fails with OOM). 
This issue has been fixed (in jdk-11+20) and test has been run (in 
tier2) without failure happening after that.

Let's move it back to tier1.

bug: https://bugs.openjdk.java.net/browse/JDK-8210353
webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/

Thanks,
Amy

diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups
--- a/test/jdk/TEST.groups
+++ b/test/jdk/TEST.groups
@@ -35,8 +35,7 @@
 ???? :jdk_lang

 ?tier1_part2 = \
-??? :jdk_util \
-??? -java/util/Arrays/TimSortStackSize2.java
+??? :jdk_util

 ?tier1_part3 = \
 ???? :jdk_math \
@@ -67,9 +66,7 @@
 ???? -sun/nio/cs/ISO8859x.java \
 ???? :jdk_other \
 ???? :jdk_text \
-??? :jdk_time \
-??? java/util/Arrays/TimSortStackSize2.java
-
+??? :jdk_time

 ?tier2_part3 = \
 ???? :jdk_net
diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java 
b/test/jdk/java/util/Arrays/TimSortStackSize2.java
--- a/test/jdk/java/util/Arrays/TimSortStackSize2.java
+++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java
@@ -25,7 +25,6 @@
 ? * @test
 ? * @bug 8072909
 ? * @summary Test TimSort stack size on big arrays
- * @key intermittent
 ? * @library /lib/testlibrary /test/lib
 ? * @modules java.management
 ? *????????? java.base/jdk.internal


From andrew_m_leonard at uk.ibm.com  Tue Sep  4 10:11:14 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Tue, 4 Sep 2018 11:11:14 +0100
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <7BF23440-41CE-43DB-AA68-BE250D286C1E@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>
 <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com>
Message-ID: <OF6762A821.CDC4AB6E-ON802582FE.003784EE-802582FE.0037F0E9@notes.na.collabserv.com>

Hi Brian/Goetz,
Yes, that seems sensible. I have created a new webrev with fdlibm compiler 
option disabled, and mediaLib code fixed:
http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/
I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3.

Are we good to go?
Thanks
Andrew

hg export:
# HG changeset patch
# User aleonard
# Date 1536055438 -3600
#      Tue Sep 04 11:03:58 2018 +0100
# Node ID c2523f285c503e8f82f1212b38de1cb54093255e
# Parent  3ee91722550680c18b977f0e00b1013323b5c9ef
8209786: JDK12 fails to build on s390x with gcc 7.3

diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk
--- a/make/lib/CoreLibraries.gmk        Tue Sep 04 14:47:55 2018 +0800
+++ b/make/lib/CoreLibraries.gmk        Tue Sep 04 11:03:58 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, \
diff -r 3ee917225506 -r c2523f285c50 
src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
--- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 14:47:55 2018 +0800
+++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 11:03:58 2018 +0100
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 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
@@ -259,18 +259,18 @@
       }
 
 #ifdef _LITTLE_ENDIAN
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
       ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ 
emask);
 
 #else /* _NO_LONGLONG */
 
 #ifdef _LITTLE_ENDIAN
-      mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 
8);
+      mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
 #else
-      mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
+      mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
 
       ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | 
(((mlib_u64*)da)[0] &~ emask);
@@ -395,9 +395,9 @@
       }
 
 #ifdef _LITTLE_ENDIAN
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
       ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask);
 
@@ -413,9 +413,9 @@
       }
 
 #ifdef _LITTLE_ENDIAN
-      emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
+      emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
 #else
-      emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
+      emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
       ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask);
 
@@ -565,9 +565,9 @@
       }
 
 #ifdef _LITTLE_ENDIAN
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
       da[0] = (dd & emask) | (da[0] &~ emask);
     }







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:     Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Cc:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>, "Lindenmaier, Goetz" 
<goetz.lindenmaier at sap.com>, 2d-dev <2d-dev at openjdk.java.net>, build-dev 
<build-dev at openjdk.java.net>, core-libs-dev 
<core-libs-dev at openjdk.java.net>, Philip Race <philip.race at oracle.com>
Date:   31/08/2018 15:44
Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux




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



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 Michael.Rasmussen at roguewave.com  Tue Sep  4 11:26:04 2018
From: Michael.Rasmussen at roguewave.com (Michael Rasmussen)
Date: Tue, 4 Sep 2018 11:26:04 +0000
Subject: StackWalker::getCallerClass throws UnsupportedOperationException
Message-ID: <BL0PR02MB491430BCA9192E6CEFE450AEE0030@BL0PR02MB4914.namprd02.prod.outlook.com>

Hi

StackWalker::getCallerClass can throw "UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive", depending on how the underlying?fetchNextBatch/fill_in_frames splits the?stacktrace.

This seems to be a result of what was introduced in JDK-8157464.

The following code example produces the exception (Tested on the jdk.java.net releases of OpenJDK 10 and 11-ea build 28):

// ----- snip ----
package com.test;

import java.lang.reflect.Method;

public class Main {
  public static void main(String[] args) throws Exception {
    Method method = Main.class.getDeclaredMethod("bar");
    Method m = Method.class.getMethod("invoke", Object.class, Object[].class);

    // get 'm' past compilation threshold
    for (int i = 0; i < 15; i++) {
      m.invoke(Main.class.getDeclaredMethod("dummy"), null, null);
    }

    m.invoke(m, m, new Object[] {method, new Object[] {null, null}});
  }

  static void dummy() { }

  static void bar() {
    System.out.println(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass());
  }
}
// ----- snip ----

The above code is constructed so Method::invoke ends up as the frame for which index==start_index in fill_in_frames, thus causing the exception.

For example output, including stackwalk debug output, see below.

// ----- snip ----
$ java -Xlog:stackwalk=debug com.test.Main
[0.154s][debug][stackwalk] Start walking: mode 6 skip 0 frames batch size 6
[0.155s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::callStackWalk
[0.156s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::beginStackWalk
[0.157s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::walk
[0.158s][debug][stackwalk]   skip  java.lang.StackStreamFactory$CallerClassFinder::findCaller
[0.159s][debug][stackwalk]   skip  java.lang.StackWalker::getCallerClass
[0.160s][debug][stackwalk] fill_in_frames limit=6 start=2 frames length=8
[0.161s][debug][stackwalk]   2: frame method:  com.test.Main::bar bci=9
[0.162s][debug][stackwalk]   3: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0
[0.162s][debug][stackwalk]   4: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100
[0.163s][debug][stackwalk]   5: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
[0.163s][debug][stackwalk]   6: frame method:  java.lang.reflect.Method::invoke bci=59
[0.168s][debug][stackwalk]   7: frame method:  jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48
[0.169s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10
[0.170s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10
[0.171s][debug][stackwalk]   2: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
[0.171s][debug][stackwalk]   3: frame method:  java.lang.reflect.Method::invoke bci=59
[0.172s][debug][stackwalk]   4: frame method:  jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48
[0.173s][debug][stackwalk]   5: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
[0.174s][debug][stackwalk]   6: frame method:  java.lang.reflect.Method::invoke bci=59
[0.175s][debug][stackwalk]   7: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0
[0.175s][debug][stackwalk]   8: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100
[0.179s][debug][stackwalk]   9: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
[0.180s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10
[0.181s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10
[0.181s][debug][stackwalk]   2: frame method:  java.lang.reflect.Method::invoke bci=59
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.test.Main.main(Main.java:15)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        ... 5 more
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        ... 8 more
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        ... 11 more
Caused by: java.lang.UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; method
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(Native Method)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(StackStreamFactory.java:386)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch(StackStreamFactory.java:322)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.peekFrame(StackStreamFactory.java:263)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.hasNext(StackStreamFactory.java:351)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.nextFrame(StackStreamFactory.java:336)
        at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:683)
        at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:612)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(StackStreamFactory.java:306)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:370)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:243)
        at java.base/java.lang.StackStreamFactory$CallerClassFinder.findCaller(StackStreamFactory.java:670)
        at java.base/java.lang.StackWalker.getCallerClass(StackWalker.java:600)
        at com.test.Main.bar(Main.java:21)
        ... 15 more
// ----- snip ----

Kind regards
/Michael

From matthias.baesken at sap.com  Tue Sep  4 11:33:44 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 4 Sep 2018 11:33:44 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <C3769928-A8BF-49D9-B032-CB671E749647@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>
 <fb1f761a8cfc4ae9970f5431062423dd@sap.com>
 <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@oracle.com>
 <38f2e1d2cbe24387bf693ac55492cf68@sap.com>
 <C3769928-A8BF-49D9-B032-CB671E749647@oracle.com>
Message-ID: <6ab99c1fc2004b32a5c08965c838d855@sap.com>

> The change looks fine. We can enhance the name if we want to support .SF
> parsing later.
> 
> Please revise your CSR and get it approved first.

Hi Max, Thanks !

I adjusted the CSR , please approve  :

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

Best regards, Matthias



> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Montag, 3. September 2018 17:14
> 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
> 
> Hi Matthias
> 
> The change looks fine. We can enhance the name if we want to support .SF
> parsing later.
> 
> Please revise your CSR and get it approved first.
> 
> Thanks
> Max
> 
> > On Sep 3, 2018, at 10:19 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hi Max,  I
> >
> > - moved getErrorPosition  method   to  Manifest.java
> > - in read() method,   removed "int offset"
> > - in  the exception message, I write now  " manifest of "  ...   (without
> mentioning a manifest name)
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/
> >
> >
> > Best regards, Matthias
> >
> >
> >> -----Original Message-----
> >> From: Weijun Wang <weijun.wang at oracle.com>
> >> Sent: Freitag, 31. August 2018 15:53
> >> 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 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 Alan.Bateman at oracle.com  Tue Sep  4 12:31:50 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Sep 2018 13:31:50 +0100
Subject: [12] RFR of JDK-8209832: Refactor
 jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
In-Reply-To: <3031698c-513c-182b-b7c7-82d102feb52d@oracle.com>
References: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>
 <5be7b2cb-6c7c-b4e1-5fde-647d41f7da33@oracle.com>
 <3031698c-513c-182b-b7c7-82d102feb52d@oracle.com>
Message-ID: <c69a6009-7931-980a-4ac5-d66c79f1f6ef@oracle.com>

On 04/09/2018 10:26, Amy Lu wrote:
>
> Thank you Alan!
>
> I updated SetupGetCallerClass:
> http://cr.openjdk.java.net/~amlu/8209832/webrev.01/
>
This looks okay to me.

-Alan

From Alan.Bateman at oracle.com  Tue Sep  4 12:34:45 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 4 Sep 2018 13:34:45 +0100
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <1ca44734-0f9e-1a4d-4479-ea72289efb44@oracle.com>



On 31/08/2018 19:42, Igor Ignatyev wrote:
> 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 
> <http://cr.openjdk.java.net/%7Eiignatyev//8210039/webrev.0-1/index.html>
>
I can't quickly verify that the code source 
"file:${test.classes}/../../../../test/lib/-" results in granting the 
permission to the right library but I assume it will fail if it's not 
correct. So I think this approach looks good to me.

-Alan

From chris.hegarty at oracle.com  Tue Sep  4 12:43:51 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 4 Sep 2018 13:43:51 +0100
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <D21B3142-47C0-42A6-BE58-8C7176312FAD@oracle.com>

Igor,

> On 31 Aug 2018, at 19:42, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> 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.

It?s bit annoying to have retrofit the test library classes with doPriv,
but I think that it is the right approach, if we intend them to be
usable with tests running with a security manager ( which we do ).

> 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 <http://cr.openjdk.java.net/~iignatyev//8210039/webrev.0-1/index.html>
I think this is fine.

Thanks,
-Chris.

From daniel.fuchs at oracle.com  Tue Sep  4 13:08:04 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 4 Sep 2018 14:08:04 +0100
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
Message-ID: <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>

Hi Igor,

Nit: You could have introduced a
private static String getProperty(String name) {
      return AccessController.doP....
}
in Platform.java to avoid the long lines.

Otherwise looks good to me too!

best regards,

-- daniel

On 31/08/2018 19:42, Igor Ignatyev wrote:
> 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.
> 


From michael.x.mcmahon at oracle.com  Tue Sep  4 13:20:00 2018
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 04 Sep 2018 14:20:00 +0100
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
Message-ID: <5B8E8680.9080707@oracle.com>

The change looks fine to me Maurizio. Maybe you could append a .$$ to 
the temporary
file name to make it less likely to overwrite something that already 
exists in /tmp

- Michael.

On 03/09/2018, 13:39, Maurizio Cimadamore wrote:
> Hi,
> following the latest updates to the idea.sh script, Mac users reported 
> issues - mostly having to do with usage of 'sed' - more specifically:
>
> * sed -i option is not portable - it has different formats in Mac vs. 
> Linux. This patch does without -i, by moving the replaced file onto a 
> temporary file, then moving such file on top of the template file in a 
> subsequent step. This should be more robust.
>
> * sed doesn't like newlines in replaced text in Mac. I've thus omitted 
> the newline from the SOURCE template - as that was mostly cosmetic.
>
> Thanks for Michael McMahon to report (and figure out how to deal with) 
> these issues, and to Alan Bateman for testing the patch.
>
> I also fixed another minor glitch, this time in the langtools-only 
> template - which was still referring to the old ant file location in 
> the various run configuration.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210318/
>
> Cheers
> Maurizio
>

From christoph.langer at sap.com  Tue Sep  4 13:22:55 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 4 Sep 2018 13:22:55 +0000
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: <3f5576906c774aef8942626d76044b0e@sap.com>

Hi Alan,

thanks for your feedback (and thanks of course to all the others who commented on this proposal).

As I've written in my first mail, this request came up because we had implemented getWidth/getHeigth APIs for console windows in our licensed VM to be used in a certain usage scenario. Now we are in the process of moving this user to an OpenJDK based VM and thought these APIs might be candidates for contribution as general purpose API. Looking at java.io.Console, it seemed the APIs would fit in there. We also thought that there could be further additions to this class.

However, we had not been aware of the history of java.io.Console and we also did not know jline project nor that it was adopted by the OpenJDK into jdk.internal.le for usage by jshell and nashorn. Thanks for pointing this out. After exploring this a bit, I'm at a point where I would go to our user and ask them to try jline. I'm quite sure they'll be able to adopt it.

Regardless of that, isn't it still worth to gradually enhance java.io.Console over time? I don't know whether we'd eventually get to a point where jline could be replaced for jshell but maybe that could be a long term goal.

If we can agree to evolve java.io.Console, I'll continue with my work for width/height APIs. But if it's consent to keep java.io.Console in its limited current state, I would also be willing to withdraw this request.

What's the way to go?
 
Best regards
Christoph

> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Montag, 27. August 2018 13:30
> To: 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 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 weijun.wang at oracle.com  Tue Sep  4 13:31:58 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 4 Sep 2018 21:31:58 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <6ab99c1fc2004b32a5c08965c838d855@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>
 <DEF53FD2-7BE4-45AB-A085-3D162F76C6E3@oracle.com>
 <38f2e1d2cbe24387bf693ac55492cf68@sap.com>
 <C3769928-A8BF-49D9-B032-CB671E749647@oracle.com>
 <6ab99c1fc2004b32a5c08965c838d855@sap.com>
Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3@oracle.com>

I've added myself as a reviewer. You might want to set scope to "JDK".

A CSR is approved by the CSR group after you finalize it. First you should propose it. If you think it's urgent or trivial, you can also fast-track it.

Read https://wiki.openjdk.java.net/display/csr/Main for more details.

Thanks
Max

> On Sep 4, 2018, at 7:33 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> The change looks fine. We can enhance the name if we want to support .SF
>> parsing later.
>> 
>> Please revise your CSR and get it approved first.
> 
> Hi Max, Thanks !
> 
> I adjusted the CSR , please approve  :
> 
> https://bugs.openjdk.java.net/browse/JDK-8207768
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Weijun Wang <weijun.wang at oracle.com>
>> Sent: Montag, 3. September 2018 17:14
>> 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
>> 
>> Hi Matthias
>> 
>> The change looks fine. We can enhance the name if we want to support .SF
>> parsing later.
>> 
>> Please revise your CSR and get it approved first.
>> 
>> Thanks
>> Max
>> 
>>> On Sep 3, 2018, at 10:19 PM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> Hi Max,  I
>>> 
>>> - moved getErrorPosition  method   to  Manifest.java
>>> - in read() method,   removed "int offset"
>>> - in  the exception message, I write now  " manifest of "  ...   (without
>> mentioning a manifest name)
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/
>>> 
>>> 
>>> Best regards, Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Weijun Wang <weijun.wang at oracle.com>
>>>> Sent: Freitag, 31. August 2018 15:53
>>>> 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 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 vyom.tewari at oracle.com  Tue Sep  4 14:04:07 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Tue, 4 Sep 2018 19:34:07 +0530
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
Message-ID: <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>



On Friday 24 August 2018 08:52 PM, Chris Hegarty wrote:
> 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.
>
Hi Chris, let me try to explain issue little bit.

The issue is a if ldap connection has already been established and then 
the LDAP directory server sends an (unsolicited) "Notice of 
Disconnection", the client's processing of this LDAP message can race 
with an application thread calling new InitialDirContext() to 
authenticate user credentials (i.e.bind) and throw NPE.

I did some analysis and found out that when server send an (unsolicited) 
"Notice of Disconnection",? LdapClient.forceClose() will be called in 
LdapClient.processUnsolicited() which is called asynchronously by the 
reader thread in Connection, this means 'LdapClient.conn' may set to 
null anytime after it received? "Notice of Disconnection".

> 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 ).
>
I agree, not setting? 'conn' to null will definitely have some impact.? 
I check the LdapClient and it looks to me it is intentional(i may be 
wrong) that 'conn' is operated on both from within synchronize blocks 
and from unsynchronize block.

LdapClient, java doc says that connection(conn) take care of it's own sync.

##################################
 ?? access from outside LdapClient must sync;
 ?*?? conn - no sync; Connection takes care of its own sync
 ?*?? unsolicited - sync Vector; multiple operations sync'ed

##################################

Please have a look and do let me know your thought on the above.

Thanks,
Vyom
> -Chris.


From daniel.fuchs at oracle.com  Tue Sep  4 14:43:19 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 4 Sep 2018 15:43:19 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
Message-ID: <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>

Hi Vyom,

IIUC, the issue only happens when connections (clients?) to the
server are pooled. I assume the server may decide to
close what it thinks is an idle connection at any time.

So what we see here is actually a race between an open
connection being retrieved from the pool, and the server
deciding to close that connection.
The connection/client is retrieved from the pool, then
unfortunately closed by the server after having been selected
for the next operation.

The question for me would be "what is the expected behavior
if the server decides to close an idle connection?"
I would expect that new InitialDirContext() should have some
way of dealing with that with retrying?
If so will leaving the 'conn' field assigned ensure that
the retry happens, or will new InitialDirContext() fail
with some other exception because the connection has
been closed? Or does the code simply assume that asynchronous
closing of the connection by the server can only happen while
it's sitting idle in the pool?

I wonder if some other mechanism could be used to reduce
and hopefully eliminate the time window in which the race
could appear. For instance taking the connection out of
the pool before closing it, instead of closing it before
taking it out of the pool, etc...

best regards,

-- daniel

On 04/09/2018 15:04, vyom tewari wrote:
> 
> 
> On Friday 24 August 2018 08:52 PM, Chris Hegarty wrote:
>> 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.
>>
> Hi Chris, let me try to explain issue little bit.
> 
> The issue is a if ldap connection has already been established and then 
> the LDAP directory server sends an (unsolicited) "Notice of 
> Disconnection", the client's processing of this LDAP message can race 
> with an application thread calling new InitialDirContext() to 
> authenticate user credentials (i.e.bind) and throw NPE.
> 
> I did some analysis and found out that when server send an (unsolicited) 
> "Notice of Disconnection",? LdapClient.forceClose() will be called in 
> LdapClient.processUnsolicited() which is called asynchronously by the 
> reader thread in Connection, this means 'LdapClient.conn' may set to 
> null anytime after it received? "Notice of Disconnection".
> 
>> 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 ).
>>
> I agree, not setting? 'conn' to null will definitely have some impact. I 
> check the LdapClient and it looks to me it is intentional(i may be 
> wrong) that 'conn' is operated on both from within synchronize blocks 
> and from unsynchronize block.
> 
> LdapClient, java doc says that connection(conn) take care of it's own sync.
> 
> ##################################
>  ?? access from outside LdapClient must sync;
>  ?*?? conn - no sync; Connection takes care of its own sync
>  ?*?? unsolicited - sync Vector; multiple operations sync'ed
> 
> ##################################
> 
> Please have a look and do let me know your thought on the above.
> 
> Thanks,
> Vyom
>> -Chris.
> 


From magnus.ihse.bursie at oracle.com  Tue Sep  4 15:38:45 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 4 Sep 2018 17:38:45 +0200
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <OF6762A821.CDC4AB6E-ON802582FE.003784EE-802582FE.0037F0E9@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>
 <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com>
 <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com>
 <OF6762A821.CDC4AB6E-ON802582FE.003784EE-802582FE.0037F0E9@notes.na.collabserv.com>
Message-ID: <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com>

Looks good to me. 

/Magnus

> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard <andrew_m_leonard at uk.ibm.com>:
> 
> Hi Brian/Goetz, 
> Yes, that seems sensible. I have created a new webrev with fdlibm compiler option disabled, and mediaLib code fixed: 
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ 
> I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. 
> 
> Are we good to go? 
> Thanks 
> Andrew 
> 
> hg export: 
> # HG changeset patch 
> # User aleonard 
> # Date 1536055438 -3600 
> #      Tue Sep 04 11:03:58 2018 +0100 
> # Node ID c2523f285c503e8f82f1212b38de1cb54093255e 
> # Parent  3ee91722550680c18b977f0e00b1013323b5c9ef 
> 8209786: JDK12 fails to build on s390x with gcc 7.3 
> 
> diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk 
> --- a/make/lib/CoreLibraries.gmk        Tue Sep 04 14:47:55 2018 +0800 
> +++ b/make/lib/CoreLibraries.gmk        Tue Sep 04 11:03:58 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, \ 
> diff -r 3ee917225506 -r c2523f285c50 src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c 
> --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c        Tue Sep 04 14:47:55 2018 +0800 
> +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c        Tue Sep 04 11:03:58 2018 +0100 
> @@ -1,5 +1,5 @@ 
>  /* 
> - * Copyright (c) 2003, 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 
> @@ -259,18 +259,18 @@ 
>        } 
>   
>  #ifdef _LITTLE_ENDIAN 
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>        ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); 
>   
>  #else /* _NO_LONGLONG */ 
>   
>  #ifdef _LITTLE_ENDIAN 
> -      mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
> +      mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
>  #else 
> -      mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
> +      mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>   
>        ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | (((mlib_u64*)da)[0] &~ emask); 
> @@ -395,9 +395,9 @@ 
>        } 
>   
>  #ifdef _LITTLE_ENDIAN 
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>        ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); 
>   
> @@ -413,9 +413,9 @@ 
>        } 
>   
>  #ifdef _LITTLE_ENDIAN 
> -      emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
> +      emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
>  #else 
> -      emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
> +      emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>        ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); 
>   
> @@ -565,9 +565,9 @@ 
>        } 
>   
>  #ifdef _LITTLE_ENDIAN 
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>        da[0] = (dd & emask) | (da[0] &~ emask); 
>      } 
> 
> 
> 
> 
> 
> 
> 
> 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:        Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> 
> Cc:        Andrew Leonard <andrew_m_leonard at uk.ibm.com>, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, 2d-dev <2d-dev at openjdk.java.net>, build-dev <build-dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>, Philip Race <philip.race at oracle.com> 
> Date:        31/08/2018 15:44 
> Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux 
> 
> 
> 
> 
> 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 
> 
> 
> 
> 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 erik.joelsson at oracle.com  Tue Sep  4 15:55:20 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 4 Sep 2018 08:55:20 -0700
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
Message-ID: <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>

Hello,

When choosing a temp file in the build, we avoid using /tmp whenever 
possible. A common pattern is instead to write to $TARGET.tmp and then 
mv that to $TARGET. Though unlikely to cause an issue, /tmp/replacement 
is a global location which is potentially risky (file permissions, 
concurrent execution etc).

Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:
> Hi,
> following the latest updates to the idea.sh script, Mac users reported 
> issues - mostly having to do with usage of 'sed' - more specifically:
>
> * sed -i option is not portable - it has different formats in Mac vs. 
> Linux. This patch does without -i, by moving the replaced file onto a 
> temporary file, then moving such file on top of the template file in a 
> subsequent step. This should be more robust.
>
> * sed doesn't like newlines in replaced text in Mac. I've thus omitted 
> the newline from the SOURCE template - as that was mostly cosmetic.
>
> Thanks for Michael McMahon to report (and figure out how to deal with) 
> these issues, and to Alan Bateman for testing the patch.
>
> I also fixed another minor glitch, this time in the langtools-only 
> template - which was still referring to the old ant file location in 
> the various run configuration.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8210318/
>
> Cheers
> Maurizio
>


From daniel.fuchs at oracle.com  Tue Sep  4 16:39:53 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 4 Sep 2018 17:39:53 +0100
Subject: RFR - 8210366: Typo in MethodHandles.Lookup: must be either be
Message-ID: <06335a60-e0c1-51b5-cbcd-72a7e90d44c8@oracle.com>

Hi,

This is a simple doc-only fix for a typo in MethodHandles.Lookup:

8210366: Typo in MethodHandles.Lookup: must be either be
https://bugs.openjdk.java.net/browse/JDK-8210366

patch:

----------------------------------------------------------------------------
diff --git 
a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 
b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -450,7 +450,7 @@
       * independently of any {@code Lookup} object.
       * <p>
       * If the desired member is {@code protected}, the usual JVM rules 
apply,
-     * including the requirement that the lookup class must be either 
be in the
+     * including the requirement that the lookup class must either be 
in the
       * same package as the desired member, or must inherit that member.
       * (See the Java Virtual Machine Specification, sections 4.9.2, 
5.4.3.5, and 6.4.)
       * In addition, if the desired member is a non-static field or method
----------------------------------------------------------------------------

best regards,

-- daniel

From joe.darcy at oracle.com  Tue Sep  4 16:40:57 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 4 Sep 2018 09:40:57 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
Message-ID: <e02cc6e3-c132-7fa2-fd92-45a49b3ef0fd@oracle.com>

Hello,

Please also create a quick CSR to cover the behavioral change.

Thanks,

-Joe


On 8/31/2018 5:17 PM, Ivan Gerasimov wrote:
> Hello!
>
> The javadoc for CharsetDecoder [1] states that an exception is thrown 
> when a non-positive number is passed in as an argument.
>
> However we only reject negative or zero numbers, but not NaN.
>
> And likewise for CharsetEncoder.
>
> Would you please help review a trivial fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
> WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/
>
> Thanks in advance!
>
> [1] 
> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float)
>


From Roger.Riggs at Oracle.com  Tue Sep  4 16:48:29 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 4 Sep 2018 12:48:29 -0400
Subject: RFR - 8210366: Typo in MethodHandles.Lookup: must be either be
In-Reply-To: <06335a60-e0c1-51b5-cbcd-72a7e90d44c8@oracle.com>
References: <06335a60-e0c1-51b5-cbcd-72a7e90d44c8@oracle.com>
Message-ID: <2501084a-2a98-4238-acd2-e05af276c9b2@Oracle.com>

Looks fine,

Regards, Roger

On 9/4/2018 12:39 PM, Daniel Fuchs wrote:
> Hi,
>
> This is a simple doc-only fix for a typo in MethodHandles.Lookup:
>
> 8210366: Typo in MethodHandles.Lookup: must be either be
> https://bugs.openjdk.java.net/browse/JDK-8210366
>
> patch:
>
> ---------------------------------------------------------------------------- 
>
> diff --git 
> a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 
> b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> @@ -450,7 +450,7 @@
> ????? * independently of any {@code Lookup} object.
> ????? * <p>
> ????? * If the desired member is {@code protected}, the usual JVM 
> rules apply,
> -???? * including the requirement that the lookup class must be either 
> be in the
> +???? * including the requirement that the lookup class must either be 
> in the
> ????? * same package as the desired member, or must inherit that member.
> ????? * (See the Java Virtual Machine Specification, sections 4.9.2, 
> 5.4.3.5, and 6.4.)
> ????? * In addition, if the desired member is a non-static field or 
> method
> ---------------------------------------------------------------------------- 
>
>
> best regards,
>
> -- daniel


From maurizio.cimadamore at oracle.com  Tue Sep  4 17:34:21 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 4 Sep 2018 18:34:21 +0100
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
Message-ID: <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:
> Hello,
>
> When choosing a temp file in the build, we avoid using /tmp whenever 
> possible. A common pattern is instead to write to $TARGET.tmp and then 
> mv that to $TARGET. Though unlikely to cause an issue, 
> /tmp/replacement is a global location which is potentially risky (file 
> permissions, concurrent execution etc).
>
> Otherwise looks good.
>
> /Erik
>
> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>> Hi,
>> following the latest updates to the idea.sh script, Mac users 
>> reported issues - mostly having to do with usage of 'sed' - more 
>> specifically:
>>
>> * sed -i option is not portable - it has different formats in Mac vs. 
>> Linux. This patch does without -i, by moving the replaced file onto a 
>> temporary file, then moving such file on top of the template file in 
>> a subsequent step. This should be more robust.
>>
>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>> omitted the newline from the SOURCE template - as that was mostly 
>> cosmetic.
>>
>> Thanks for Michael McMahon to report (and figure out how to deal 
>> with) these issues, and to Alan Bateman for testing the patch.
>>
>> I also fixed another minor glitch, this time in the langtools-only 
>> template - which was still referring to the old ant file location in 
>> the various run configuration.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>
>> Cheers
>> Maurizio
>>
>


From erik.joelsson at oracle.com  Tue Sep  4 17:50:29 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 4 Sep 2018 10:50:29 -0700
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
 <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
Message-ID: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:
> Hi Erik,
> would $TARGET be set by make?
>
> Maurizio
>
>
> On 04/09/18 16:55, Erik Joelsson wrote:
>> Hello,
>>
>> When choosing a temp file in the build, we avoid using /tmp whenever 
>> possible. A common pattern is instead to write to $TARGET.tmp and 
>> then mv that to $TARGET. Though unlikely to cause an issue, 
>> /tmp/replacement is a global location which is potentially risky 
>> (file permissions, concurrent execution etc).
>>
>> Otherwise looks good.
>>
>> /Erik
>>
>> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>>> Hi,
>>> following the latest updates to the idea.sh script, Mac users 
>>> reported issues - mostly having to do with usage of 'sed' - more 
>>> specifically:
>>>
>>> * sed -i option is not portable - it has different formats in Mac 
>>> vs. Linux. This patch does without -i, by moving the replaced file 
>>> onto a temporary file, then moving such file on top of the template 
>>> file in a subsequent step. This should be more robust.
>>>
>>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>>> omitted the newline from the SOURCE template - as that was mostly 
>>> cosmetic.
>>>
>>> Thanks for Michael McMahon to report (and figure out how to deal 
>>> with) these issues, and to Alan Bateman for testing the patch.
>>>
>>> I also fixed another minor glitch, this time in the langtools-only 
>>> template - which was still referring to the old ant file location in 
>>> the various run configuration.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>>
>>> Cheers
>>> Maurizio
>>>
>>
>


From maurizio.cimadamore at oracle.com  Tue Sep  4 17:56:49 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 4 Sep 2018 18:56:49 +0100
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
 <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
 <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
Message-ID: <3b98f4cc-f444-1a84-eaea-e303c1f06077@oracle.com>

Ah - thanks for the tip, I'll give that a try

Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:
> Hello,
>
> $TARGET was just pseudo code. In your case it's $1.tmp.
>
> /Erik
>
>
> On 2018-09-04 10:34, Maurizio Cimadamore wrote:
>> Hi Erik,
>> would $TARGET be set by make?
>>
>> Maurizio
>>
>>
>> On 04/09/18 16:55, Erik Joelsson wrote:
>>> Hello,
>>>
>>> When choosing a temp file in the build, we avoid using /tmp whenever 
>>> possible. A common pattern is instead to write to $TARGET.tmp and 
>>> then mv that to $TARGET. Though unlikely to cause an issue, 
>>> /tmp/replacement is a global location which is potentially risky 
>>> (file permissions, concurrent execution etc).
>>>
>>> Otherwise looks good.
>>>
>>> /Erik
>>>
>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> following the latest updates to the idea.sh script, Mac users 
>>>> reported issues - mostly having to do with usage of 'sed' - more 
>>>> specifically:
>>>>
>>>> * sed -i option is not portable - it has different formats in Mac 
>>>> vs. Linux. This patch does without -i, by moving the replaced file 
>>>> onto a temporary file, then moving such file on top of the template 
>>>> file in a subsequent step. This should be more robust.
>>>>
>>>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>>>> omitted the newline from the SOURCE template - as that was mostly 
>>>> cosmetic.
>>>>
>>>> Thanks for Michael McMahon to report (and figure out how to deal 
>>>> with) these issues, and to Alan Bateman for testing the patch.
>>>>
>>>> I also fixed another minor glitch, this time in the langtools-only 
>>>> template - which was still referring to the old ant file location 
>>>> in the various run configuration.
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>


From mandy.chung at oracle.com  Tue Sep  4 17:58:43 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 4 Sep 2018 10:58:43 -0700
Subject: StackWalker::getCallerClass throws UnsupportedOperationException
In-Reply-To: <BL0PR02MB491430BCA9192E6CEFE450AEE0030@BL0PR02MB4914.namprd02.prod.outlook.com>
References: <BL0PR02MB491430BCA9192E6CEFE450AEE0030@BL0PR02MB4914.namprd02.prod.outlook.com>
Message-ID: <24fa9fa6-cbf3-6e82-a57b-eb5f19b0c392@oracle.com>

Thanks for reporting this.?? I have created:
 ?? https://bugs.openjdk.java.net/browse/JDK-8210375

and will look into it.

Mandy

On 9/4/18 4:26 AM, Michael Rasmussen wrote:
> Hi
>
> StackWalker::getCallerClass can throw "UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive", depending on how the underlying?fetchNextBatch/fill_in_frames splits the?stacktrace.
>
> This seems to be a result of what was introduced in JDK-8157464.
>
> The following code example produces the exception (Tested on the jdk.java.net releases of OpenJDK 10 and 11-ea build 28):
>
> // ----- snip ----
> package com.test;
>
> import java.lang.reflect.Method;
>
> public class Main {
>    public static void main(String[] args) throws Exception {
>      Method method = Main.class.getDeclaredMethod("bar");
>      Method m = Method.class.getMethod("invoke", Object.class, Object[].class);
>
>      // get 'm' past compilation threshold
>      for (int i = 0; i < 15; i++) {
>        m.invoke(Main.class.getDeclaredMethod("dummy"), null, null);
>      }
>
>      m.invoke(m, m, new Object[] {method, new Object[] {null, null}});
>    }
>
>    static void dummy() { }
>
>    static void bar() {
>      System.out.println(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass());
>    }
> }
> // ----- snip ----
>
> The above code is constructed so Method::invoke ends up as the frame for which index==start_index in fill_in_frames, thus causing the exception.
>
> For example output, including stackwalk debug output, see below.
>
> // ----- snip ----
> $ java -Xlog:stackwalk=debug com.test.Main
> [0.154s][debug][stackwalk] Start walking: mode 6 skip 0 frames batch size 6
> [0.155s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::callStackWalk
> [0.156s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::beginStackWalk
> [0.157s][debug][stackwalk]   skip  java.lang.StackStreamFactory$AbstractStackWalker::walk
> [0.158s][debug][stackwalk]   skip  java.lang.StackStreamFactory$CallerClassFinder::findCaller
> [0.159s][debug][stackwalk]   skip  java.lang.StackWalker::getCallerClass
> [0.160s][debug][stackwalk] fill_in_frames limit=6 start=2 frames length=8
> [0.161s][debug][stackwalk]   2: frame method:  com.test.Main::bar bci=9
> [0.162s][debug][stackwalk]   3: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0
> [0.162s][debug][stackwalk]   4: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100
> [0.163s][debug][stackwalk]   5: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
> [0.163s][debug][stackwalk]   6: frame method:  java.lang.reflect.Method::invoke bci=59
> [0.168s][debug][stackwalk]   7: frame method:  jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48
> [0.169s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10
> [0.170s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10
> [0.171s][debug][stackwalk]   2: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
> [0.171s][debug][stackwalk]   3: frame method:  java.lang.reflect.Method::invoke bci=59
> [0.172s][debug][stackwalk]   4: frame method:  jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48
> [0.173s][debug][stackwalk]   5: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
> [0.174s][debug][stackwalk]   6: frame method:  java.lang.reflect.Method::invoke bci=59
> [0.175s][debug][stackwalk]   7: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0
> [0.175s][debug][stackwalk]   8: frame method:  jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100
> [0.179s][debug][stackwalk]   9: frame method:  jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6
> [0.180s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10
> [0.181s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10
> [0.181s][debug][stackwalk]   2: frame method:  java.lang.reflect.Method::invoke bci=59
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>          at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          at com.test.Main.main(Main.java:15)
> Caused by: java.lang.reflect.InvocationTargetException
>          at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>          at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          ... 5 more
> Caused by: java.lang.reflect.InvocationTargetException
>          at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>          at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          ... 8 more
> Caused by: java.lang.reflect.InvocationTargetException
>          at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          ... 11 more
> Caused by: java.lang.UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; method
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(Native Method)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(StackStreamFactory.java:386)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch(StackStreamFactory.java:322)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.peekFrame(StackStreamFactory.java:263)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.hasNext(StackStreamFactory.java:351)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.nextFrame(StackStreamFactory.java:336)
>          at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:683)
>          at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:612)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(StackStreamFactory.java:306)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:370)
>          at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:243)
>          at java.base/java.lang.StackStreamFactory$CallerClassFinder.findCaller(StackStreamFactory.java:670)
>          at java.base/java.lang.StackWalker.getCallerClass(StackWalker.java:600)
>          at com.test.Main.bar(Main.java:21)
>          ... 15 more
> // ----- snip ----
>
> Kind regards
> /Michael


From mandy.chung at oracle.com  Tue Sep  4 18:07:51 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 4 Sep 2018 11:07:51 -0700
Subject: [12] RFR of JDK-8209832: Refactor
 jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
In-Reply-To: <3031698c-513c-182b-b7c7-82d102feb52d@oracle.com>
References: <a4cd9675-9b1f-1bef-69a4-2123a8566984@oracle.com>
 <5be7b2cb-6c7c-b4e1-5fde-647d41f7da33@oracle.com>
 <3031698c-513c-182b-b7c7-82d102feb52d@oracle.com>
Message-ID: <f83b9f24-484f-1b02-985b-14ae11ccc123@oracle.com>



On 9/4/18 2:26 AM, Amy Lu wrote:
>
> I updated SetupGetCallerClass:
> http://cr.openjdk.java.net/~amlu/8209832/webrev.01/
>

Looks fine to me.

Mandy

From ivan.gerasimov at oracle.com  Tue Sep  4 18:08:41 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 4 Sep 2018 11:08:41 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <CA+kOe0-w1ihNiu=SD0XC+-R2KfSV4p+HA=-1euhqZdX7japqGg@mail.gmail.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <5B8C288C.2090406@oracle.com>
 <3cb94f39-9dab-d400-82a8-e1245660d007@oracle.com>
 <7772e7c9-61f7-73ff-5cde-ec50c907bb85@oracle.com>
 <effae057-b0fa-29d3-c4d8-d19d974086f3@oracle.com>
 <CA+kOe0-w1ihNiu=SD0XC+-R2KfSV4p+HA=-1euhqZdX7japqGg@mail.gmail.com>
Message-ID: <a0094aec-746a-b234-082e-9bb8a0496f1e@oracle.com>

Thanks everyone for reviewing!

As suggested, I added a test to cover CharsetEncoder constructor and a 
sanity check that the constructor doesn't throw given valid arguments.

http://cr.openjdk.java.net/~igerasim/8210285/01/webrev/

With kind regards,

Ivan


On 9/3/18 8:31 AM, Martin Buchholz wrote:
> Looks good to me.  I would add a call to
> new MyDecoder(ascii, 0.5f, 1.5f)
> to make sure all calls to the constructor don't throw (because e.g. 
> for ASCII we know the correct values are 1.0f).
>
> (In any case it feels like an API design mistake - the Charset itself 
> should be the source of truth about charsPerByte)
>
> On Mon, Sep 3, 2018 at 3:57 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 03/09/2018 05:54, Ivan Gerasimov wrote:
>
>         Thanks Sherman and Stuart for the review!
>
>         On 9/2/18 2:45 PM, Stuart Marks wrote:
>
>             Yes, the fix itself looks fine. Quite subtle, good catch.
>
>             But should this have a regression test? I can imagine
>             somebody coming along later and "simplifying" (!(... >
>             ...)) to (... <= ...) which would reintroduce the bug.
>
>         Yes, there is a regression test added:
>         http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/test/jdk/java/nio/charset/CharsetDecoder/NaNinCtor.java.html
>         <http://cr.openjdk.java.net/%7Eigerasim/8210285/00/webrev/test/jdk/java/nio/charset/CharsetDecoder/NaNinCtor.java.html>
>
>
>     The update to Charset-X-Coder.java.template looks okay. The
>     changes also CharsetEncoder so we'll need test coverage for that too.
>
>     -Alan
>
>

-- 
With kind regards,
Ivan Gerasimov


From naoto.sato at oracle.com  Tue Sep  4 18:14:45 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 4 Sep 2018 11:14:45 -0700
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
Message-ID: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8210142/webrev.00/

The fix is a simple one line change, which is to make the sharedZone 
field consistent with the cloned TimeZone instance in Calendar.clone().

Naoto

From ivan.gerasimov at oracle.com  Tue Sep  4 18:25:59 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 4 Sep 2018 11:25:59 -0700
Subject: RFR 8210285 : CharsetDecoder/Encoder's constructor does not
 reject NaN
In-Reply-To: <e02cc6e3-c132-7fa2-fd92-45a49b3ef0fd@oracle.com>
References: <19bba420-9d75-46b0-8337-9111c8df864f@oracle.com>
 <e02cc6e3-c132-7fa2-fd92-45a49b3ef0fd@oracle.com>
Message-ID: <4e3c254a-ea26-0161-f525-d9c370711e21@oracle.com>


On 9/4/18 9:40 AM, joe darcy wrote:
> Hello,
>
> Please also create a quick CSR to cover the behavioral change.
>
Okay, here it is:
https://bugs.openjdk.java.net/browse/JDK-8210377

Would you please help review it?

Thanks in advance!

Ivan


> Thanks,
>
> -Joe
>
>
> On 8/31/2018 5:17 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The javadoc for CharsetDecoder [1] states that an exception is thrown 
>> when a non-positive number is passed in as an argument.
>>
>> However we only reject negative or zero numbers, but not NaN.
>>
>> And likewise for CharsetEncoder.
>>
>> Would you please help review a trivial fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/
>>
>> Thanks in advance!
>>
>> [1] 
>> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/charset/CharsetDecoder.html#%3Cinit%3E(java.nio.charset.Charset,float,float)
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From Roger.Riggs at Oracle.com  Tue Sep  4 19:02:13 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 4 Sep 2018 15:02:13 -0400
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
 <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
Message-ID: <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>

Hi Martin, Ivan,

Thanks for the suggestions.

Update in place:
http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/

On 8/29/2018 5:36 PM, Martin Buchholz wrote:
> 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.
>
Not trivial since a long cannot hold the combined time of millis(long) 
and nanos (long) in a TimeUnit(Nanos)
and the cumulative wait time needs to be measured by System.nanoTime().

> 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
ok
>
> (I prefer the variable name "startTime")
ok
>
> (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))
ok,
>
> (I would reorder clauses to first check the common case millis > 0, 
> then millis == 0, last the error case millis < 0)
ok
>
> (it's a bad API that millis < 0 is an error)
too late for a behavior change though I suppose its in the direction of 
not getting error instead of the opposite....


An Observation:

Join(ms) and join(ms, ns) might wait a bit longer than strictly 
necessary because the bottom out in Object.wait(ms).
It might be better if both ended up calling Object.wait(ms, ns).
But since Object.wait(ms,ns) rounds up to Object.wait(ms) that won't 
make a difference and to take advantage
of a finer clock resolution would mean native/vm changes to support 
object.wait(ms, ns).

I'm inclined to address only the immediate issues raised in the early 
return and the clock dependency now.

(BTW, I found no tests for Thread.sleep or .join.)

Thanks, Roger

>
>
> On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto: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/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-thread-early-8098798/>
>
>     Thanks, Roger
>
>


From sergei.tsypanov at yandex.ru  Tue Sep  4 19:14:21 2018
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 04 Sep 2018 21:14:21 +0200
Subject: [PATCH] Simplification of TreeMap
Message-ID: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>

Hi,

currently (latest code of JDK 11) an instance of TreeMap created with no-arg contructor has nullable comparator i.e. utilizes no comparator.

As it comes from the code, a TreeMap created with nullable comparator works exactly as a TreeMap created with comparator provided by Comparator.naturalOrder(). This is also explicitly specifid in Javadoc.

I propose to initialize default comparator of TreeMap with instance of Comparator returned by Comparator.naturalOrder() instead of null.
This allows to remove the code responsible for handling nullable comparator, e. g. TreeMap::getEntryUsingComparator can be completely removed in favour of TreeMap::getEntry.
Similar simplification available for TreeMap::put, TreeMap::compare, EntrySpliterator::getComparator.

I've prepared a patch for this.
The patch contains both described major change and some tiny clean-ups e. g. utilization of Objects::requireNonNull where appropriate and Objects::equals instead of hand-written TreeMap::valEquals.

TreeMapTest is green after my changes.

Regards,
Sergey Tsypanov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: treemap.patch
Type: text/x-diff
Size: 13581 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20180904/108ae4e9/treemap-0001.patch>

From Roger.Riggs at Oracle.com  Tue Sep  4 19:31:05 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 4 Sep 2018 15:31:05 -0400
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
Message-ID: <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>

Hi Naoto,

The spec for clone doesn't say whether the clone should share or not 
share the TimeZone.
Did you consider that if sharedZone was true , *not* to clone the TimeZone?
It would still get cloned when requested from getTimeZone().

This does seem somewhat safer not to change the cloning behavior but I 
don't think the behavior would be observable.

The current code and test is fine, except for reducing the potential for 
sharing the TimeZone.

Thanks, Roger

On 9/4/2018 2:14 PM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8210142
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>
> The fix is a simple one line change, which is to make the sharedZone 
> field consistent with the cloned TimeZone instance in Calendar.clone().
>
> Naoto


From ivan.gerasimov at oracle.com  Tue Sep  4 19:38:53 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 4 Sep 2018 12:38:53 -0700
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
 <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
 <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
Message-ID: <7d6bb15b-6ba5-42d5-7769-095bb9cb77a1@oracle.com>

Thank you Roger!

I'm not sure if it plays any significant role, but an unnecessary call 
to nanoTime() after wait(delay) could be avoided with the code like this:

     if (millis > 0) {
         if (isAlive()) {
             final long startTime = System.nanoTime();
             long delay = millis;
             do {
                 wait(delay);
             } while (isAlive() && (delay = millis - 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime)) > 0);
         }
     } else if (millis == 0) {


With kind regards,
Ivan


On 9/4/18 12:02 PM, Roger Riggs wrote:
> Hi Martin, Ivan,
>
> Thanks for the suggestions.
>
> Update in place:
> http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>
> On 8/29/2018 5:36 PM, Martin Buchholz wrote:
>> 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.
>>
> Not trivial since a long cannot hold the combined time of millis(long) 
> and nanos (long) in a TimeUnit(Nanos)
> and the cumulative wait time needs to be measured by System.nanoTime().
>
>> 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
> ok
>>
>> (I prefer the variable name "startTime")
> ok
>>
>> (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))
> ok,
>>
>> (I would reorder clauses to first check the common case millis > 0, 
>> then millis == 0, last the error case millis < 0)
> ok
>>
>> (it's a bad API that millis < 0 is an error)
> too late for a behavior change though I suppose its in the direction 
> of not getting error instead of the opposite....
>
>
> An Observation:
>
> Join(ms) and join(ms, ns) might wait a bit longer than strictly 
> necessary because the bottom out in Object.wait(ms).
> It might be better if both ended up calling Object.wait(ms, ns).
> But since Object.wait(ms,ns) rounds up to Object.wait(ms) that won't 
> make a difference and to take advantage
> of a finer clock resolution would mean native/vm changes to support 
> object.wait(ms, ns).
>
> I'm inclined to address only the immediate issues raised in the early 
> return and the clock dependency now.
>
> (BTW, I found no tests for Thread.sleep or .join.)
>
> Thanks, Roger
>
>>
>>
>> On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto: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/
>> <http://cr.openjdk.java.net/%7Erriggs/webrev-thread-early-8098798/>
>>
>>     Thanks, Roger
>>
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From forax at univ-mlv.fr  Tue Sep  4 19:41:47 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 4 Sep 2018 21:41:47 +0200 (CEST)
Subject: [PATCH] Simplification of TreeMap
In-Reply-To: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
Message-ID: <61858614.592160.1536090107966.JavaMail.zimbra@u-pem.fr>

Hi Sergey,
if think the code is as it is because it's faster to check for the null comparator and have an ad-hoc code for this special case than using Comparator.naturalOrder(),
obviously, it's not may be true anymore, so you should test that there is no perf regression when creating your patch.

regards,
R?mi

----- Mail original -----
> De: "?????? ???????" <sergei.tsypanov at yandex.ru>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 4 Septembre 2018 21:14:21
> Objet: [PATCH] Simplification of TreeMap

> Hi,
> 
> currently (latest code of JDK 11) an instance of TreeMap created with no-arg
> contructor has nullable comparator i.e. utilizes no comparator.
> 
> As it comes from the code, a TreeMap created with nullable comparator works
> exactly as a TreeMap created with comparator provided by
> Comparator.naturalOrder(). This is also explicitly specifid in Javadoc.
> 
> I propose to initialize default comparator of TreeMap with instance of
> Comparator returned by Comparator.naturalOrder() instead of null.
> This allows to remove the code responsible for handling nullable comparator, e.
> g. TreeMap::getEntryUsingComparator can be completely removed in favour of
> TreeMap::getEntry.
> Similar simplification available for TreeMap::put, TreeMap::compare,
> EntrySpliterator::getComparator.
> 
> I've prepared a patch for this.
> The patch contains both described major change and some tiny clean-ups e. g.
> utilization of Objects::requireNonNull where appropriate and Objects::equals
> instead of hand-written TreeMap::valEquals.
> 
> TreeMapTest is green after my changes.
> 
> Regards,
> Sergey Tsypanov

From jdk at fiolino.de  Tue Sep  4 20:02:38 2018
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Tue, 4 Sep 2018 22:02:38 +0200
Subject: [PATCH] Simplification of TreeMap
In-Reply-To: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
Message-ID: <7c89fc87-b612-9c23-cb60-eb34e9212a1e@fiolino.de>

Hi Sergey,

I was also wondering why TreeMap doesn't just use a default comparator
and always checks for null instead.

The problem with your patch is that deserialized TreeMap instances which
were serialized from a previous version would still have the comparator
set to null, thus resulting in a NPE after your patch. And you can't
easily fix this because comparator is a final field.

Best,
Michael


On 04.09.2018 21:14, ?????? ??????? wrote:
> Hi,
> 
> currently (latest code of JDK 11) an instance of TreeMap created with no-arg contructor has nullable comparator i.e. utilizes no comparator.
> 
> As it comes from the code, a TreeMap created with nullable comparator works exactly as a TreeMap created with comparator provided by Comparator.naturalOrder(). This is also explicitly specifid in Javadoc.
> 
> I propose to initialize default comparator of TreeMap with instance of Comparator returned by Comparator.naturalOrder() instead of null.
> This allows to remove the code responsible for handling nullable comparator, e. g. TreeMap::getEntryUsingComparator can be completely removed in favour of TreeMap::getEntry.
> Similar simplification available for TreeMap::put, TreeMap::compare, EntrySpliterator::getComparator.
> 
> I've prepared a patch for this.
> The patch contains both described major change and some tiny clean-ups e. g. utilization of Objects::requireNonNull where appropriate and Objects::equals instead of hand-written TreeMap::valEquals.
> 
> TreeMapTest is green after my changes.
> 
> Regards,
> Sergey Tsypanov
> 
> 


From naoto.sato at oracle.com  Tue Sep  4 20:12:38 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 4 Sep 2018 13:12:38 -0700
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
Message-ID: <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>

Hi Roger,

Yes, I considered that too, but did not change the behavior and just to 
maintain the field consistent. I agree that it would not be observable 
via the public Calendar API, but some apps (like how the submitter found 
it) may be doing something using reflection.

Naoto

On 9/4/18 12:31 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> The spec for clone doesn't say whether the clone should share or not 
> share the TimeZone.
> Did you consider that if sharedZone was true , *not* to clone the TimeZone?
> It would still get cloned when requested from getTimeZone().
> 
> This does seem somewhat safer not to change the cloning behavior but I 
> don't think the behavior would be observable.
> 
> The current code and test is fine, except for reducing the potential for 
> sharing the TimeZone.
> 
> Thanks, Roger
> 
> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>
>> The fix is a simple one line change, which is to make the sharedZone 
>> field consistent with the cloned TimeZone instance in Calendar.clone().
>>
>> Naoto
> 

From roger.riggs at oracle.com  Tue Sep  4 20:41:40 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 4 Sep 2018 16:41:40 -0400
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
 <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
Message-ID: <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>

Hi Naoto,

That access via reflection is going to go away sometime; so I'm not too 
concerned about
maintaining compatibility of the internal implementation.
I think I'd rather see the memory savings, however small.
Let see if anyone else has a recommendation.

Roger


On 9/4/18 4:12 PM, Naoto Sato wrote:
> Hi Roger,
>
> Yes, I considered that too, but did not change the behavior and just 
> to maintain the field consistent. I agree that it would not be 
> observable via the public Calendar API, but some apps (like how the 
> submitter found it) may be doing something using reflection.
>
> Naoto
>
> On 9/4/18 12:31 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> The spec for clone doesn't say whether the clone should share or not 
>> share the TimeZone.
>> Did you consider that if sharedZone was true , *not* to clone the 
>> TimeZone?
>> It would still get cloned when requested from getTimeZone().
>>
>> This does seem somewhat safer not to change the cloning behavior but 
>> I don't think the behavior would be observable.
>>
>> The current code and test is fine, except for reducing the potential 
>> for sharing the TimeZone.
>>
>> Thanks, Roger
>>
>> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>>
>>> The proposed fix is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>>
>>> The fix is a simple one line change, which is to make the sharedZone 
>>> field consistent with the cloned TimeZone instance in Calendar.clone().
>>>
>>> Naoto
>>


From naoto.sato at oracle.com  Tue Sep  4 21:19:31 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 4 Sep 2018 14:19:31 -0700
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
 <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
 <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>
Message-ID: <18c083fe-e22e-be08-97c6-d8a7dc02e68b@oracle.com>

Hi Roger,

I tentatively tried to return a shared zone within a cloned Calendar. 
One test failed: java/util/Calendar/CalendarRegression.Test4136399, 
where it makes sure that the cloned Calendar object hash code should be 
different for the better distribution. Although the comment does not 
reflect the current implementation (getTimeZone() returning cloned 
zone), the intention here seems to have the better hash distribution for 
cloned objects.

Naoto

On 9/4/18 1:41 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> That access via reflection is going to go away sometime; so I'm not too 
> concerned about
> maintaining compatibility of the internal implementation.
> I think I'd rather see the memory savings, however small.
> Let see if anyone else has a recommendation.
> 
> Roger
> 
> 
> On 9/4/18 4:12 PM, Naoto Sato wrote:
>> Hi Roger,
>>
>> Yes, I considered that too, but did not change the behavior and just 
>> to maintain the field consistent. I agree that it would not be 
>> observable via the public Calendar API, but some apps (like how the 
>> submitter found it) may be doing something using reflection.
>>
>> Naoto
>>
>> On 9/4/18 12:31 PM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> The spec for clone doesn't say whether the clone should share or not 
>>> share the TimeZone.
>>> Did you consider that if sharedZone was true , *not* to clone the 
>>> TimeZone?
>>> It would still get cloned when requested from getTimeZone().
>>>
>>> This does seem somewhat safer not to change the cloning behavior but 
>>> I don't think the behavior would be observable.
>>>
>>> The current code and test is fine, except for reducing the potential 
>>> for sharing the TimeZone.
>>>
>>> Thanks, Roger
>>>
>>> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>>>
>>>> The proposed fix is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>>>
>>>> The fix is a simple one line change, which is to make the sharedZone 
>>>> field consistent with the cloned TimeZone instance in Calendar.clone().
>>>>
>>>> Naoto
>>>
> 

From igor.ignatyev at oracle.com  Tue Sep  4 22:02:17 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 4 Sep 2018 15:02:17 -0700
Subject: RFR(M) : 8210039 : move OSInfo to top level testlibrary
In-Reply-To: <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>
References: <DBDBCC24-D247-4DC3-96AD-D51399E18F02@oracle.com>
 <36320bf8-3f80-0e69-14b7-9d4a442380d0@oracle.com>
 <DDBB2989-AB8D-4485-9D1B-35FF3FC0397D@oracle.com>
 <1CDBCB62-B6AD-4F5C-9725-BF4E4DF74B94@oracle.com>
 <4a1e575f-f7e3-1c7c-f415-37c44f08ac77@oracle.com>
Message-ID: <9F6E234B-23EE-4E6C-9144-EEBCBA7F6CFB@oracle.com>

Daniel, Chris, Alan,

thank you for your review.

I've pushed it w/ Platfform::privilegedGetProperty method added to shorten lines in Platform.java

Cheers,
-- Igor


> On Sep 4, 2018, at 6:08 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Igor,
> 
> Nit: You could have introduced a
> private static String getProperty(String name) {
>     return AccessController.doP....
> }
> in Platform.java to avoid the long lines.
> 
> Otherwise looks good to me too!
> 
> best regards,
> 
> -- daniel
> 
> On 31/08/2018 19:42, Igor Ignatyev wrote:
>> 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.
> 


From martinrb at google.com  Wed Sep  5 00:00:56 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 4 Sep 2018 17:00:56 -0700
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
 <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
 <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
Message-ID: <CA+kOe0_D=WP-VPsdyt2YA8uGp4K-20uJu_RBNrQAMq55bobg5g@mail.gmail.com>

On Tue, Sep 4, 2018 at 12:02 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>
>> One sharp corner is that wait(0) waits forever, and TimeUnit conversion
>> truncates.  You can probably avoid those problems via TimeUnit.timedWait.
>>
>> Not trivial since a long cannot hold the combined time of millis(long)
> and nanos (long) in a TimeUnit(Nanos)
> and the cumulative wait time needs to be measured by System.nanoTime().


This sort of code is never trivial, but ... in j.u.c. we usually convert to
nanos as soon as we can.  Yes, we lose some range for large inputs - we
saturate to 2^63 nanoseconds.  But 292 years ought to be enough for ...
people calling wait, if not for paleontologists.   And nanoTime will wrap
around then anyways.

From rob.mckenna at oracle.com  Wed Sep  5 01:05:26 2018
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 5 Sep 2018 02:05:26 +0100
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
In-Reply-To: <b95ebc4c-ee1d-dd11-34e8-493f71d416c4@oracle.com>
References: <20180903214804.GA2868@vimes>
 <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com>
 <b95ebc4c-ee1d-dd11-34e8-493f71d416c4@oracle.com>
Message-ID: <20180905010526.GA4025@vimes>

Thanks for the reviews folks.

I believe the following captures your recommended changes:

http://cr.openjdk.java.net/~robm/8139965/webrev.02/

W.r.t. testing I think this area has been difficult to test
traditionally. I'll have a dig through the existing testbase (and I'll
get back to you) to see if there's anything similar but afaik most tests
simply mimic a bindable dummy ldap server.

Vyom, are you aware of any more rigorous tests / ldap test frameworks?

    -Rob

On 04/09/18 10:22, Daniel Fuchs wrote:
> Hi Rob,
> 
> I concur with Chris.
> completed needs to be volatile and close() needs to
> set a flag and use offer like cancel().
> 
> The condition for testing for closed then becomes
> that the flag is set and the queue is empty or has EOF
> as its head.
> 
> Is there any way this could be tested by a regression
> test?
> 
> best regards,
> 
> -- daniel
> 
> On 04/09/2018 10:00, Chris Hegarty wrote:
> > Rob,
> > 
> > > On 3 Sep 2018, at 22:48, Rob McKenna <rob.mckenna at oracle.com> wrote:
> > > 
> > > Hi folks,
> > > 
> > > I'd like to get a re-review of this change:
> > > 
> > > https://bugs.openjdk.java.net/browse/JDK-8139965 <https://bugs.openjdk.java.net/browse/JDK-8139965>
> > 
> > This issue is closed as `will not fix`. I presume you will re-open it before pushing.
> > 
> > > http://cr.openjdk.java.net/~robm/8139965/webrev/ <http://cr.openjdk.java.net/~robm/8139965/webrev/>
> > 
> > 
> > 43     private boolean completed;
> > Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted )
> > 
> > LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it?
> > 
> > Please check the indentation of LdapRequest.java L103 ( in
> > the new file ). It appears, in the webrev, that the trailing `}` is
> > not lined up.
> > 
> > The indentation doesn?t look right here either.
> >   624             if (nparent) {
> >   625                 LdapRequest ldr = pendingRequests;
> >   626                 while (ldr != null) {
> >   627                     ldr.close();
> >   628                         ldr = ldr.next;
> >   629                     }
> >   630                 }
> >   631             }
> > 
> > -Chris
> > 
> 

From igor.ignatyev at oracle.com  Wed Sep  5 01:33:07 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 4 Sep 2018 18:33:07 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
Message-ID: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
> 2375 lines changed: 322 ins; 1662 del; 391 mod

Hi all,

could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process?

there were a few differences b/w implementations which are addressed by the patch:
 - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method
 - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
 - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them.
 - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest.

the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible.  

webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
testing: tier1-tier3 + :jdk_svc
JBS: https://bugs.openjdk.java.net/browse/JDK-8210112

Thanks,
-- Igor 


From matthias.baesken at sap.com  Wed Sep  5 08:07:02 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 5 Sep 2018 08:07:02 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
Message-ID: <2bc2e45729c640d9afab76d108ec6951@sap.com>

Hi Max,  thanks for adding  yourself  as a reviewer.

I set the CSR  ( https://bugs.openjdk.java.net/browse/JDK-8207768  ) to proposed.

Best regards, Matthias

> 
> Message: 2
> Date: Tue, 4 Sep 2018 21:31:58 +0800
> From: Weijun Wang <weijun.wang at oracle.com>
> To: "Baesken, Matthias" <matthias.baesken at sap.com>
> Cc: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>,
> 	"core-libs-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
> Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3 at oracle.com>
> Content-Type: text/plain;	charset=us-ascii
> 
> I've added myself as a reviewer. You might want to set scope to "JDK".
> 
> A CSR is approved by the CSR group after you finalize it. First you should
> propose it. If you think it's urgent or trivial, you can also fast-track it.
> 
> Read https://wiki.openjdk.java.net/display/csr/Main for more details.
> 
> Thanks
> Max
> 
> > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> >> The change looks fine. We can enhance the name if we want to support
> .SF
> >> parsing later.
> >>
> >> Please revise your CSR and get it approved first.
> >
> > Hi Max, Thanks !
> >
> > I adjusted the CSR , please approve  :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8207768
> >
> > Best regards, Matthias


From daniel.fuchs at oracle.com  Wed Sep  5 08:53:47 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 5 Sep 2018 09:53:47 +0100
Subject: RFR: 8139965 - Hang seen when using
 com.sun.jndi.ldap.search.replyQueueSize
In-Reply-To: <20180905010526.GA4025@vimes>
References: <20180903214804.GA2868@vimes>
 <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com>
 <b95ebc4c-ee1d-dd11-34e8-493f71d416c4@oracle.com>
 <20180905010526.GA4025@vimes>
Message-ID: <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com>

Hi Rob,

That looks better but I believe that:

1. closed should be volatile since it's read from outside
    synchronized block

2. it seems there might be a race where the last response
    received could be dropped, if the connection is closed
    just after it's been pulled from the queue.

So I would suggest exchanging:

  115         if (isClosed()) {
  116             return null;
  117         }
  118
  119         return result;

with:

              return result == EOF ? null : result;

best regards,

-- daniel

On 05/09/2018 02:05, Rob McKenna wrote:
> Thanks for the reviews folks.
> 
> I believe the following captures your recommended changes:
> 
> http://cr.openjdk.java.net/~robm/8139965/webrev.02/
> 
> W.r.t. testing I think this area has been difficult to test
> traditionally. I'll have a dig through the existing testbase (and I'll
> get back to you) to see if there's anything similar but afaik most tests
> simply mimic a bindable dummy ldap server.
> 
> Vyom, are you aware of any more rigorous tests / ldap test frameworks?
> 
>      -Rob
> 
> On 04/09/18 10:22, Daniel Fuchs wrote:
>> Hi Rob,
>>
>> I concur with Chris.
>> completed needs to be volatile and close() needs to
>> set a flag and use offer like cancel().
>>
>> The condition for testing for closed then becomes
>> that the flag is set and the queue is empty or has EOF
>> as its head.
>>
>> Is there any way this could be tested by a regression
>> test?
>>
>> best regards,
>>
>> -- daniel
>>
>> On 04/09/2018 10:00, Chris Hegarty wrote:
>>> Rob,
>>>
>>>> On 3 Sep 2018, at 22:48, Rob McKenna <rob.mckenna at oracle.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I'd like to get a re-review of this change:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8139965 <https://bugs.openjdk.java.net/browse/JDK-8139965>
>>>
>>> This issue is closed as `will not fix`. I presume you will re-open it before pushing.
>>>
>>>> http://cr.openjdk.java.net/~robm/8139965/webrev/ <http://cr.openjdk.java.net/~robm/8139965/webrev/>
>>>
>>>
>>> 43     private boolean completed;
>>> Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted )
>>>
>>> LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it?
>>>
>>> Please check the indentation of LdapRequest.java L103 ( in
>>> the new file ). It appears, in the webrev, that the trailing `}` is
>>> not lined up.
>>>
>>> The indentation doesn?t look right here either.
>>>    624             if (nparent) {
>>>    625                 LdapRequest ldr = pendingRequests;
>>>    626                 while (ldr != null) {
>>>    627                     ldr.close();
>>>    628                         ldr = ldr.next;
>>>    629                     }
>>>    630                 }
>>>    631             }
>>>
>>> -Chris
>>>
>>


From maurizio.cimadamore at oracle.com  Wed Sep  5 11:42:27 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 5 Sep 2018 12:42:27 +0100
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
 <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
 <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
Message-ID: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com>

Here's the modified webrev - as suggested, I replaced /tmp/replacement 
with $1.tmp

http://cr.openjdk.java.net/~mcimadamore/8210318_v2/

Thanks
Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:
> Hello,
>
> $TARGET was just pseudo code. In your case it's $1.tmp.
>
> /Erik
>
>
> On 2018-09-04 10:34, Maurizio Cimadamore wrote:
>> Hi Erik,
>> would $TARGET be set by make?
>>
>> Maurizio
>>
>>
>> On 04/09/18 16:55, Erik Joelsson wrote:
>>> Hello,
>>>
>>> When choosing a temp file in the build, we avoid using /tmp whenever 
>>> possible. A common pattern is instead to write to $TARGET.tmp and 
>>> then mv that to $TARGET. Though unlikely to cause an issue, 
>>> /tmp/replacement is a global location which is potentially risky 
>>> (file permissions, concurrent execution etc).
>>>
>>> Otherwise looks good.
>>>
>>> /Erik
>>>
>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> following the latest updates to the idea.sh script, Mac users 
>>>> reported issues - mostly having to do with usage of 'sed' - more 
>>>> specifically:
>>>>
>>>> * sed -i option is not portable - it has different formats in Mac 
>>>> vs. Linux. This patch does without -i, by moving the replaced file 
>>>> onto a temporary file, then moving such file on top of the template 
>>>> file in a subsequent step. This should be more robust.
>>>>
>>>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>>>> omitted the newline from the SOURCE template - as that was mostly 
>>>> cosmetic.
>>>>
>>>> Thanks for Michael McMahon to report (and figure out how to deal 
>>>> with) these issues, and to Alan Bateman for testing the patch.
>>>>
>>>> I also fixed another minor glitch, this time in the langtools-only 
>>>> template - which was still referring to the old ant file location 
>>>> in the various run configuration.
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>
>>
>


From magnus.ihse.bursie at oracle.com  Wed Sep  5 11:51:59 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 5 Sep 2018 13:51:59 +0200
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
 <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
 <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
 <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com>
Message-ID: <4c7bdfd1-3516-ad52-8d7b-748ac06b97f2@oracle.com>

On 2018-09-05 13:42, Maurizio Cimadamore wrote:
> Here's the modified webrev - as suggested, I replaced /tmp/replacement 
> with $1.tmp
>
> http://cr.openjdk.java.net/~mcimadamore/8210318_v2/

Looks good to me.

/Magnus

>
> Thanks
> Maurizio
>
>
> On 04/09/18 18:50, Erik Joelsson wrote:
>> Hello,
>>
>> $TARGET was just pseudo code. In your case it's $1.tmp.
>>
>> /Erik
>>
>>
>> On 2018-09-04 10:34, Maurizio Cimadamore wrote:
>>> Hi Erik,
>>> would $TARGET be set by make?
>>>
>>> Maurizio
>>>
>>>
>>> On 04/09/18 16:55, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> When choosing a temp file in the build, we avoid using /tmp 
>>>> whenever possible. A common pattern is instead to write to 
>>>> $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause 
>>>> an issue, /tmp/replacement is a global location which is 
>>>> potentially risky (file permissions, concurrent execution etc).
>>>>
>>>> Otherwise looks good.
>>>>
>>>> /Erik
>>>>
>>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> following the latest updates to the idea.sh script, Mac users 
>>>>> reported issues - mostly having to do with usage of 'sed' - more 
>>>>> specifically:
>>>>>
>>>>> * sed -i option is not portable - it has different formats in Mac 
>>>>> vs. Linux. This patch does without -i, by moving the replaced file 
>>>>> onto a temporary file, then moving such file on top of the 
>>>>> template file in a subsequent step. This should be more robust.
>>>>>
>>>>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>>>>> omitted the newline from the SOURCE template - as that was mostly 
>>>>> cosmetic.
>>>>>
>>>>> Thanks for Michael McMahon to report (and figure out how to deal 
>>>>> with) these issues, and to Alan Bateman for testing the patch.
>>>>>
>>>>> I also fixed another minor glitch, this time in the langtools-only 
>>>>> template - which was still referring to the old ant file location 
>>>>> in the various run configuration.
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>>>>
>>>>> Cheers
>>>>> Maurizio
>>>>>
>>>>
>>>
>>
>


From magnus.ihse.bursie at oracle.com  Wed Sep  5 12:11:57 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 5 Sep 2018 14:11:57 +0200
Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
Message-ID: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>

When I removed (mostly) all mapfiles for the JDK libraries, building of 
libjsig started failing on Solaris, and that part was backed out.

Here's a new, and improved solution to remove the mapfile for libjsig, 
even on Solaris.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed Sep  5 12:58:06 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 5 Sep 2018 14:58:06 +0200
Subject: RFR: JDK-8059019 sdp.conf.template should move from unix to solaris
Message-ID: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>

The file sdp.conf.template is copied only when building for solaris, but 
it resides in the unix source directory.

Bug: https://bugs.openjdk.java.net/browse/JDK-8059019
Patch inline:
diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk
+++ b/make/copy/Copy-java.base.gmk
@@ -185,7 +185,7 @@

 ?ifeq ($(OPENJDK_TARGET_OS), solaris)
 ?? $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \
-????? FILES := 
$(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, 
\
+????? FILES := 
$(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/conf/sdp/sdp.conf.template, \
 ?????? DEST := $(CONF_DST_DIR)/sdp, \
 ?? ))

diff --git a/src/java.base/unix/conf/sdp/sdp.conf.template 
b/src/java.base/solaris/conf/sdp/sdp.conf.template
rename from src/java.base/unix/conf/sdp/sdp.conf.template
rename to src/java.base/solaris/conf/sdp/sdp.conf.template

/Magnus

From sgehwolf at redhat.com  Wed Sep  5 13:12:25 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 05 Sep 2018 15:12:25 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
Message-ID: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
         - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers for
StrictMath:

Function      | before     | after
----------------------------------------------
sin           | 0m33.382s  | 0m18.731s
cos           | 0m31.562s  | 0m18.796s
tan           | 0m33.657s  | 0m21.093s
atan          | 0m5.714s   | 0m4.902s
log           | 0m6.212s   | 0m4.439s
log10         | 0m7.946s   | 0m5.543s
sqrt          | 0m0.481s   | 0m0.449s
cbrt          | 0m5.295s   | 0m5.214s
tanh          | 0m1.404s   | 0m1.307s
log1p         | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2         | 0m8.037s   | 0m5.668s
hypot         | 0m2.171s   | 0m2.147s

Thoughts?

Thanks,
Severin



From Alan.Bateman at oracle.com  Wed Sep  5 13:26:23 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Sep 2018 14:26:23 +0100
Subject: RFR: JDK-8059019 sdp.conf.template should move from unix to
 solaris
In-Reply-To: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>
References: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>
Message-ID: <bbd8cb3a-f9eb-7dab-192d-97b35ce5619d@oracle.com>

On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
> The file sdp.conf.template is copied only when building for solaris, 
> but it resides in the unix source directory.
SDP is legacy now and we should probably think about removing it, esp. 
with the rsocket support in the works.

In the mean time, as the SDP support is compiled into libnet on Linux, 
then we should copy the template in the Linux image too.

-Alan

From roger.riggs at oracle.com  Wed Sep  5 14:07:17 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 5 Sep 2018 10:07:17 -0400
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <18c083fe-e22e-be08-97c6-d8a7dc02e68b@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
 <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
 <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>
 <18c083fe-e22e-be08-97c6-d8a7dc02e68b@oracle.com>
Message-ID: <35c46503-afea-50af-2f93-4ab3e447ba2b@oracle.com>

Hi Naoto,

That sounds like a test issue.? I would not expect a cloned Calendar or 
TimeZone to have a different hashCode.
None of the fields involved in the hashCode/equals should be different. 
(Or I'm missing something about them).

Thanks, Roger


On 9/4/18 5:19 PM, Naoto Sato wrote:
> Hi Roger,
>
> I tentatively tried to return a shared zone within a cloned Calendar. 
> One test failed: java/util/Calendar/CalendarRegression.Test4136399, 
> where it makes sure that the cloned Calendar object hash code should 
> be different for the better distribution. Although the comment does 
> not reflect the current implementation (getTimeZone() returning cloned 
> zone), the intention here seems to have the better hash distribution 
> for cloned objects.
>
> Naoto
>
> On 9/4/18 1:41 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> That access via reflection is going to go away sometime; so I'm not 
>> too concerned about
>> maintaining compatibility of the internal implementation.
>> I think I'd rather see the memory savings, however small.
>> Let see if anyone else has a recommendation.
>>
>> Roger
>>
>>
>> On 9/4/18 4:12 PM, Naoto Sato wrote:
>>> Hi Roger,
>>>
>>> Yes, I considered that too, but did not change the behavior and just 
>>> to maintain the field consistent. I agree that it would not be 
>>> observable via the public Calendar API, but some apps (like how the 
>>> submitter found it) may be doing something using reflection.
>>>
>>> Naoto
>>>
>>> On 9/4/18 12:31 PM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> The spec for clone doesn't say whether the clone should share or 
>>>> not share the TimeZone.
>>>> Did you consider that if sharedZone was true , *not* to clone the 
>>>> TimeZone?
>>>> It would still get cloned when requested from getTimeZone().
>>>>
>>>> This does seem somewhat safer not to change the cloning behavior 
>>>> but I don't think the behavior would be observable.
>>>>
>>>> The current code and test is fine, except for reducing the 
>>>> potential for sharing the TimeZone.
>>>>
>>>> Thanks, Roger
>>>>
>>>> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>>>>
>>>>> The proposed fix is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>>>>
>>>>> The fix is a simple one line change, which is to make the 
>>>>> sharedZone field consistent with the cloned TimeZone instance in 
>>>>> Calendar.clone().
>>>>>
>>>>> Naoto
>>>>
>>


From christoph.langer at sap.com  Wed Sep  5 15:01:54 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 5 Sep 2018 15:01:54 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <2bc2e45729c640d9afab76d108ec6951@sap.com>
References: <2bc2e45729c640d9afab76d108ec6951@sap.com>
Message-ID: <75b6f813364f42678d87851aac533346@sap.com>

Hi Matthias,

I have reviewed your change, +1

I also reviewed the CSR.

Best regards
Christoph

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Mittwoch, 5. September 2018 10:07
> To: security-dev at openjdk.java.net; Weijun Wang
> <weijun.wang at oracle.com>; core-libs-dev at openjdk.java.net
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest
> parsing of jar archives
> 
> Hi Max,  thanks for adding  yourself  as a reviewer.
> 
> I set the CSR  ( https://bugs.openjdk.java.net/browse/JDK-8207768  ) to
> proposed.
> 
> Best regards, Matthias
> 
> >
> > Message: 2
> > Date: Tue, 4 Sep 2018 21:31:58 +0800
> > From: Weijun Wang <weijun.wang at oracle.com>
> > To: "Baesken, Matthias" <matthias.baesken at sap.com>
> > Cc: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>,
> > 	"core-libs-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
> > Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3 at oracle.com>
> > Content-Type: text/plain;	charset=us-ascii
> >
> > I've added myself as a reviewer. You might want to set scope to "JDK".
> >
> > A CSR is approved by the CSR group after you finalize it. First you should
> > propose it. If you think it's urgent or trivial, you can also fast-track it.
> >
> > Read https://wiki.openjdk.java.net/display/csr/Main for more details.
> >
> > Thanks
> > Max
> >
> > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias
> > <matthias.baesken at sap.com> wrote:
> > >
> > >> The change looks fine. We can enhance the name if we want to support
> > .SF
> > >> parsing later.
> > >>
> > >> Please revise your CSR and get it approved first.
> > >
> > > Hi Max, Thanks !
> > >
> > > I adjusted the CSR , please approve  :
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8207768
> > >
> > > Best regards, Matthias


From xueming.shen at oracle.com  Wed Sep  5 15:38:41 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 05 Sep 2018 08:38:41 -0700
Subject: RFR JDK-8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip:
 The process cannot access the file because it is being used by another process
Message-ID: <5B8FF881.9070009@oracle.com>

Hi

Please help review the change for JDK-8210394.

issue: https://bugs.openjdk.java.net/browse/JDK-8210394
webrev: http://cr.openjdk.java.net/~sherman/8210394/webrev

It appears the "zipfile" for testing is opened with "new 
ZipFile(...).stream()..." without
explicit close might be the direct trigger of the failure. (a mach5 job 
with the proposed
fix seems to pass without this failure)

Thanks,
Sherman

From thomas.stuefe at gmail.com  Wed Sep  5 15:45:10 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Sep 2018 17:45:10 +0200
Subject: Question about libjava/childproc.c
Message-ID: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>

Hi all,

I just saw that in childproc.c, between fork and exec, in the child
process, we attempt to close all file descriptors. Which is fine and
good practice.

See function "closeDecriptors()" in libjava/childproc.c.

That function attempts to read /proc/fd to get all open file
descriptors and then closes them. For that, it uses readdir().
However, it has to make some weird magic workarounds since readdir()
itself may be internally implemented using a file descriptor:

86    /* We're trying to close all file descriptors, but opendir() might
87     * itself be implemented using a file descriptor, and we certainly
88     * don't want to close that while it's in use.  We assume that if
89     * opendir() is implemented using a file descriptor, then it uses
90     * the lowest numbered file descriptor, just like open().  So we
91     * close a couple explicitly.  */
92
93    close(from_fd);          /* for possible use by opendir() */
94    close(from_fd + 1);      /* another one for good luck */

My question would be, could we not - instead of straight away closing
the file descriptor - set them all to FD_CLOEXEC instead?

for (every fd in /proc/fd)
   fcntl(fd, F_SETFD, FD_CLOEXEC)

?

That way we will close them once we do exec(), which is what we
actually want, no?

Thanks & Regards, Thomas

From Alan.Bateman at oracle.com  Wed Sep  5 15:53:40 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Sep 2018 16:53:40 +0100
Subject: RFR JDK-8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip:
 The process cannot access the file because it is being used by another
 process
In-Reply-To: <5B8FF881.9070009@oracle.com>
References: <5B8FF881.9070009@oracle.com>
Message-ID: <6dd3816d-aee8-c289-799d-92c911d2b215@oracle.com>



On 05/09/2018 16:38, Xueming Shen wrote:
> Hi
>
> Please help review the change for JDK-8210394.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8210394
> webrev: http://cr.openjdk.java.net/~sherman/8210394/webrev
>
> It appears the "zipfile" for testing is opened with "new 
> ZipFile(...).stream()..." without
> explicit close might be the direct trigger of the failure. (a mach5 
> job with the proposed
> fix seems to pass without this failure)
This looks okay. It's possible that AV software could cause some 
interference and the deleteIfExists to fail but time will tell if this 
is the case.

-Alan

From james.laskey at oracle.com  Wed Sep  5 15:54:35 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 5 Sep 2018 12:54:35 -0300
Subject: RFR JDK-8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip:
 The process cannot access the file because it is being used by another
 process
In-Reply-To: <5B8FF881.9070009@oracle.com>
References: <5B8FF881.9070009@oracle.com>
Message-ID: <1D14E84D-EE82-49BD-93E7-5D9040C43B71@oracle.com>

+1

> On Sep 5, 2018, at 12:38 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi
> 
> Please help review the change for JDK-8210394.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8210394
> webrev: http://cr.openjdk.java.net/~sherman/8210394/webrev
> 
> It appears the "zipfile" for testing is opened with "new ZipFile(...).stream()..." without
> explicit close might be the direct trigger of the failure. (a mach5 job with the proposed
> fix seems to pass without this failure)
> 
> Thanks,
> Sherman


From Alan.Bateman at oracle.com  Wed Sep  5 16:06:05 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Sep 2018 17:06:05 +0100
Subject: Question about libjava/childproc.c
In-Reply-To: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
Message-ID: <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>

On 05/09/2018 16:45, Thomas St?fe wrote:
> :
>
> My question would be, could we not - instead of straight away closing
> the file descriptor - set them all to FD_CLOEXEC instead?
>
This comes up periodically but even if we do that then we still need 
this code to catch the places where FD_CLOEXEC isn't set.

Note that there a thread net-dev trying to do this for sockets. The 
scenario there seems to be someone calling fork/exec directory and not 
using ProcessBuilder. The patch under discussion is not complete but it 
helps.

-Alan

From jcbeyler at google.com  Wed Sep  5 03:01:17 2018
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 4 Sep 2018 20:01:17 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
Message-ID: <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>

Hi Igor,

I reviewed the webrev but I noticed two things:

- Small nit:
  - In
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html
     - I thought we don't have to flush as the stream gets closed and by
closing flushes the stream, isn't that redundant then?

-
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html
  - Seems we could refactor a bit this no?
     - If we put the Future and ByteArrayOutputStream in a separate class
(ex TaskStream), then the constructor and the getters could be factorized:

class TaskStream {
   private final ByteArrayOutputStream buffer;
   private Future<Void> task;

   public TaskStream(InputStream stream) {
      buffer = new ByteArrayOutputStream();
      task = new StreamPumper(stream, buffer).process();
   }

    public String getBuffer() {
      try {
        task.get();
        return buffer.toString();
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new OutputBufferException(e);
      } catch (ExecutionException | CancellationException e) {
        throw new OutputBufferException(e);
      }
    }
}

+  class LazyOutputBuffer implements OutputBuffer {

+    private final TaskStream stderr;

+    private final TaskStream stdout;

+    private final Process p;++    private LazyOutputBuffer(Process p)
{+      this.p = p;

+      stderr = new TaskStream(p.getInputStream());

+      stdout = new TaskStream(p.getErrorStream());+    }++
@Override+    public String getStdout() {

+      return stdout.getBuffer();

+    }+    @Override+    public String getStderr() {

+       return stderr.getBuffer()+    }


I think it is more clear, what do you think?


Apart from those two elements, it looks good to me :), nice refactor!

Jc



On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
> > 2375 lines changed: 322 ins; 1662 del; 391 mod
>
> Hi all,
>
> could you please review the patch which removes
> jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages
> w/ corresponding classes from jdk.test.lib.process?
>
> there were a few differences b/w implementations which are addressed by
> the patch:
>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String)
> method
>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any
> purposes, while j.t.OutputBuffer provided lazy access to a process's cout,
> cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface
> w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated
> j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of
> storing them.
>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but
> j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests
> which really depend on absence of '-cp' and updated them to create
> ProcessBuilder directly, namely JavaClassPathTest and
> AppendToClassPathModuleTest.
>
> the rest of the patch is straightforward change of used classes w/ adding
> @library /test/lib if necessary and removing @library /lib/testlibrary if
> possible.
>
> webrev:
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
> testing: tier1-tier3 + :jdk_svc
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112
>
> Thanks,
> -- Igor
>
>

-- 

Thanks,
Jc

From thomas.stuefe at gmail.com  Wed Sep  5 16:15:01 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Sep 2018 18:15:01 +0200
Subject: Question about libjava/childproc.c
In-Reply-To: <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
Message-ID: <CAA-vtUxkqTUqtWjW2WPAWNQyRyy6rRCoHyRDenb--ugLWsrsUA@mail.gmail.com>

Hi Alan,

On Wed, Sep 5, 2018 at 6:06 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 05/09/2018 16:45, Thomas St?fe wrote:
>>
>> :
>>
>> My question would be, could we not - instead of straight away closing
>> the file descriptor - set them all to FD_CLOEXEC instead?
>>
> This comes up periodically but even if we do that then we still need this
> code to catch the places where FD_CLOEXEC isn't set.

Oh, I did not want to get rid of this coding, just change it like this:

 @@ -109,7 +100,7 @@
         int fd;
         if (isAsciiDigit(dirp->d_name[0]) &&
             (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd + 2)
-            close(fd);
+            fcntl(fc, F_SETFD, FD_CLOEXEC);
     }

     closedir(dp);


So, keep looping thru the open file descriptors, but instead of
closing them - which would interfere with the file descriptor
opendir() is using - just set them to FD_CLOEXEC.

That would not interfere with opendir() and we could remove the weird
workaround above, which tries to outguess the opendir() implementation
and proactivly closes file descriptors.

I did not test this though so I may be on the wrong track.

>
> Note that there a thread net-dev trying to do this for sockets. The scenario
> there seems to be someone calling fork/exec directory and not using
> ProcessBuilder. The patch under discussion is not complete but it helps.
>
> -Alan

From martinrb at google.com  Wed Sep  5 16:16:43 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Sep 2018 09:16:43 -0700
Subject: Question about libjava/childproc.c
In-Reply-To: <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
Message-ID: <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>

Alan: Thomas seems to be suggesting setting the FD_CLOEXEC flag after fork
but before exec, which is a slightly different idea.

Thomas: This is an interesting idea.  Historically the usual strategy was
to close all the file descriptors explicitly, perhaps before FD_CLOEXEC was
something we could rely on.  One might expect the explicit close to be more
efficient, since it involves fewer calls into libc.  As always, the process
code is rather brittle and we don't like to touch it if it's working.

We would probably want to use the idiom at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html

    flags = fcntl(fd, F_GETFD);
    if (flags == -1)
        /* Handle error */;
    flags |= FD_CLOEXEC;
    if (fcntl(fd, F_SETFD, flags) == -1)
        /* Handle error */;"




On Wed, Sep 5, 2018 at 9:06 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 05/09/2018 16:45, Thomas St?fe wrote:
>
>> :
>>
>> My question would be, could we not - instead of straight away closing
>> the file descriptor - set them all to FD_CLOEXEC instead?
>>
>> This comes up periodically but even if we do that then we still need this
> code to catch the places where FD_CLOEXEC isn't set.
>
> Note that there a thread net-dev trying to do this for sockets. The
> scenario there seems to be someone calling fork/exec directory and not
> using ProcessBuilder. The patch under discussion is not complete but it
> helps.
>
> -Alan
>

From thomas.stuefe at gmail.com  Wed Sep  5 16:23:41 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Sep 2018 18:23:41 +0200
Subject: Question about libjava/childproc.c
In-Reply-To: <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
Message-ID: <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>

On Wed, Sep 5, 2018 at 6:16 PM, Martin Buchholz <martinrb at google.com> wrote:
> Alan: Thomas seems to be suggesting setting the FD_CLOEXEC flag after fork
> but before exec, which is a slightly different idea.
>
> Thomas: This is an interesting idea.  Historically the usual strategy was to
> close all the file descriptors explicitly, perhaps before FD_CLOEXEC was
> something we could rely on.  One might expect the explicit close to be more
> efficient, since it involves fewer calls into libc.  As always, the process
> code is rather brittle and we don't like to touch it if it's working.
>
> We would probably want to use the idiom at
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
>
>     flags = fcntl(fd, F_GETFD);
>     if (flags == -1)
>         /* Handle error */;
>     flags |= FD_CLOEXEC;
>     if (fcntl(fd, F_SETFD, flags) == -1)
>         /* Handle error */;"
>

Of course. My example removed all other flags. Thanks for pointing that out :)

However, I believe we do not really know if the current coding always
works, or? If we accidentally close the opendir file descriptor,
because the magic workaround above did not work, readdir() would
probably just fail and we would silently exit the loop, leaving the
remaining file descriptors open?

Since all this happens between vfork and exec we cannot do any decent
error handling here. Even what little we do is way outside the allowed
spec for vfork().

..Thomas

>
>
>
> On Wed, Sep 5, 2018 at 9:06 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>>
>> On 05/09/2018 16:45, Thomas St?fe wrote:
>>>
>>> :
>>>
>>> My question would be, could we not - instead of straight away closing
>>> the file descriptor - set them all to FD_CLOEXEC instead?
>>>
>> This comes up periodically but even if we do that then we still need this
>> code to catch the places where FD_CLOEXEC isn't set.
>>
>> Note that there a thread net-dev trying to do this for sockets. The
>> scenario there seems to be someone calling fork/exec directory and not using
>> ProcessBuilder. The patch under discussion is not complete but it helps.
>>
>> -Alan
>
>

From martinrb at google.com  Wed Sep  5 16:43:01 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Sep 2018 09:43:01 -0700
Subject: Question about libjava/childproc.c
In-Reply-To: <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
Message-ID: <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>

On Wed, Sep 5, 2018 at 9:23 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

>
> Since all this happens between vfork and exec we cannot do any decent
> error handling here. Even what little we do is way outside the allowed
> spec for vfork().
>

Well we do have a fallback if closeDescriptors fails.  But on closer
inspection we don't check for error conditions in readdir

http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html

Upon successful completion, *readdir*() shall return a pointer to an object
of type *struct dirent*. When an error is encountered, a null pointer shall
be returned and *errno* shall be set to indicate the error. When the end of
the directory is encountered, a null pointer shall be returned and *errno* is
not changed.

So before the readdir loop we should set errno to 0.  Then when readdir
returns NULL, we should check whether errno is non-zero.

---

We do have a way of reporting errno to the parent.  See WhyCantJohnnyExec.

From erik.joelsson at oracle.com  Wed Sep  5 16:57:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Sep 2018 09:57:44 -0700
Subject: RFR 8210318: idea.sh script doesn't work on Mac
In-Reply-To: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com>
References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com>
 <f3eecdf3-b15c-9841-f1f2-2210da07dd7c@oracle.com>
 <c5003f96-e6bd-0aa3-9814-bfb4312ca9f3@oracle.com>
 <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com>
 <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com>
Message-ID: <c271724f-984e-1c5f-d5cf-0b4beeced02b@oracle.com>

Looks good, thanks!

/Erik


On 2018-09-05 04:42, Maurizio Cimadamore wrote:
> Here's the modified webrev - as suggested, I replaced /tmp/replacement 
> with $1.tmp
>
> http://cr.openjdk.java.net/~mcimadamore/8210318_v2/
>
> Thanks
> Maurizio
>
>
> On 04/09/18 18:50, Erik Joelsson wrote:
>> Hello,
>>
>> $TARGET was just pseudo code. In your case it's $1.tmp.
>>
>> /Erik
>>
>>
>> On 2018-09-04 10:34, Maurizio Cimadamore wrote:
>>> Hi Erik,
>>> would $TARGET be set by make?
>>>
>>> Maurizio
>>>
>>>
>>> On 04/09/18 16:55, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> When choosing a temp file in the build, we avoid using /tmp 
>>>> whenever possible. A common pattern is instead to write to 
>>>> $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause 
>>>> an issue, /tmp/replacement is a global location which is 
>>>> potentially risky (file permissions, concurrent execution etc).
>>>>
>>>> Otherwise looks good.
>>>>
>>>> /Erik
>>>>
>>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> following the latest updates to the idea.sh script, Mac users 
>>>>> reported issues - mostly having to do with usage of 'sed' - more 
>>>>> specifically:
>>>>>
>>>>> * sed -i option is not portable - it has different formats in Mac 
>>>>> vs. Linux. This patch does without -i, by moving the replaced file 
>>>>> onto a temporary file, then moving such file on top of the 
>>>>> template file in a subsequent step. This should be more robust.
>>>>>
>>>>> * sed doesn't like newlines in replaced text in Mac. I've thus 
>>>>> omitted the newline from the SOURCE template - as that was mostly 
>>>>> cosmetic.
>>>>>
>>>>> Thanks for Michael McMahon to report (and figure out how to deal 
>>>>> with) these issues, and to Alan Bateman for testing the patch.
>>>>>
>>>>> I also fixed another minor glitch, this time in the langtools-only 
>>>>> template - which was still referring to the old ant file location 
>>>>> in the various run configuration.
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/
>>>>>
>>>>> Cheers
>>>>> Maurizio
>>>>>
>>>>
>>>
>>
>


From erik.joelsson at oracle.com  Wed Sep  5 17:00:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Sep 2018 10:00:09 -0700
Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
In-Reply-To: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
Message-ID: <cce527c8-9725-a801-c02e-346e1115e96d@oracle.com>

Hello,

Looks good to me.

/Erik


On 2018-09-05 05:11, Magnus Ihse Bursie wrote:
> When I removed (mostly) all mapfiles for the JDK libraries, building 
> of libjsig started failing on Solaris, and that part was backed out.
>
> Here's a new, and improved solution to remove the mapfile for libjsig, 
> even on Solaris.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01
>
> /Magnus
>


From sergei.tsypanov at yandex.ru  Wed Sep  5 18:30:18 2018
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 05 Sep 2018 20:30:18 +0200
Subject: [PATCH] Simplification of TreeMap
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
 <7c89fc87-b612-9c23-cb60-eb34e9212a1e@fiolino.de>
Message-ID: <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>

Hi Michael,

thanks for pointing out this serialization concern, I didn't think about it at all.

I've wrote a simple test for serialization of patched TreeMap and it works without errors for both no-args constructor and constructor with comparator:

public class TreeMapSerialization {
    public static void main(String[] args) throws Exception {
        TreeMap<Integer, String> serialized = new TreeMap<>(Comparator.reverseOrder());
        serialized.put(1, "1");
        serialized.put(2, "2");

        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(baos);

        oos.writeObject(serialized);
        oos.flush();
        baos.flush();
        oos.close();
        baos.close();

        ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
        ObjectInputStream ois = new ObjectInputStream(bais);

        TreeMap<Integer, String> deserialized = (TreeMap<Integer, String>) ois.readObject();
        deserialized.put(3, "3");

        System.out.println(deserialized);
    }
}


I hope I don't miss anything, so there shouldn't be any serialization issues.

Regards,
Sergey Tsypanov

From thomas.stuefe at gmail.com  Wed Sep  5 18:43:43 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Sep 2018 20:43:43 +0200
Subject: Question about libjava/childproc.c
In-Reply-To: <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
 <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
Message-ID: <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>

On Wed, Sep 5, 2018 at 6:43 PM, Martin Buchholz <martinrb at google.com> wrote:
>
>
> On Wed, Sep 5, 2018 at 9:23 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>>
>>
>> Since all this happens between vfork and exec we cannot do any decent
>> error handling here. Even what little we do is way outside the allowed
>> spec for vfork().
>
>
> Well we do have a fallback if closeDescriptors fails.  But on closer
> inspection we don't check for error conditions in readdir
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
>
> Upon successful completion, readdir() shall return a pointer to an object of
> type struct dirent. When an error is encountered, a null pointer shall be
> returned and errno shall be set to indicate the error. When the end of the
> directory is encountered, a null pointer shall be returned and errno is not
> changed.
>
>
> So before the readdir loop we should set errno to 0.  Then when readdir
> returns NULL, we should check whether errno is non-zero.
>

Note that if we fix this, we may run into errors which were hidden
before, namely if we really accidentally did close the file descriptor
used by opendir(). Currently, even if some file descriptors remain
unclosed, that may not necessarily lead to an error. But with your
suggested error handling we would straight away fail.

Therefore I would combine both fixes - add readdir error handling and
also change to fcntl(FD_CLOEXEC).

> ---
>
> We do have a way of reporting errno to the parent.  See WhyCantJohnnyExec.

Ah I see.

Btw, do you know what happens when we modify errno in a vforked child
process? Would that not modify errno in the parent process too? (errno
is probably implemented as thread local variable, and since the parent
thread sleeps until we exec this may still be okay, or?).

---

A bit more background, if you are interested:

A long time ago, at SAP we swapped Oracle's implementation of
Runtime.exec on Unix against a completely homegrown one. The reason
was that we needed a really robust implementation for our customers,
and with the then current implementation we kept running into
limitations and pathological corner cases. Especially on outlier
platforms like HPUX or AS/400.

This was long before OpenJDK existed, so there was no way for us to
just fix the coding upstream. But now there is, so at regular
intervals I keep eyeing our implementation to check if we could merge.

The main difference between our version and the upstream one is: we
switched to vfork() for the obvious performance reasons. But since
vfork() is scary we implemented the exec-twice-trick with a little
in-between binary. The main purpose was to minimize the window between
vfork() and the first exec(), where we operate inside the parent
process memory. Everything "dangerous" - calling libc functions,
scanning the proc file system, error handling, tracing etc - is
deferred to after the first exec. And since that window is minimal,
that also reduces the chance of signals in the child process harming
the parent.

Later Oracle introduced something very similar with the jspawnhelper.
But I see that jspawnhelper is not used at all for the vfork() case,
just for posix_spawn(), yes?

Thanks, Thomas

From martinrb at google.com  Wed Sep  5 19:13:46 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Sep 2018 12:13:46 -0700
Subject: [PATCH] Simplification of TreeMap
In-Reply-To: <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
 <7c89fc87-b612-9c23-cb60-eb34e9212a1e@fiolino.de>
 <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>
Message-ID: <CA+kOe0-QXjLyS02ooa7UqfciF8QYkuZvjO_5PzSo=w5BFQnoXw@mail.gmail.com>

??????, they say "If it ain't broke, don't fix it".  Your implementation is
indeed more maintainable, but TreeMap has been rather stable and is
unlikely to see much maintenance!  (unless value types makes it compelling).

One of many problems with serialization is that cross-version compatibility
is hard to test and so usually ends up untested.

On Wed, Sep 5, 2018 at 11:30 AM, ?????? ??????? <sergei.tsypanov at yandex.ru>
wrote:

> Hi Michael,
>
> thanks for pointing out this serialization concern, I didn't think about
> it at all.
>
> I've wrote a simple test for serialization of patched TreeMap and it works
> without errors for both no-args constructor and constructor with comparator:
>
> public class TreeMapSerialization {
>     public static void main(String[] args) throws Exception {
>         TreeMap<Integer, String> serialized = new TreeMap<>(Comparator.
> reverseOrder());
>         serialized.put(1, "1");
>         serialized.put(2, "2");
>
>         ByteArrayOutputStream baos = new ByteArrayOutputStream();
>         ObjectOutputStream oos = new ObjectOutputStream(baos);
>
>         oos.writeObject(serialized);
>         oos.flush();
>         baos.flush();
>         oos.close();
>         baos.close();
>
>         ByteArrayInputStream bais = new ByteArrayInputStream(baos.
> toByteArray());
>         ObjectInputStream ois = new ObjectInputStream(bais);
>
>         TreeMap<Integer, String> deserialized = (TreeMap<Integer, String>)
> ois.readObject();
>         deserialized.put(3, "3");
>
>         System.out.println(deserialized);
>     }
> }
>
>
> I hope I don't miss anything, so there shouldn't be any serialization
> issues.
>
> Regards,
> Sergey Tsypanov
>

From joe.darcy at oracle.com  Wed Sep  5 19:15:12 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 5 Sep 2018 12:15:12 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
Message-ID: <8ac7400d-00af-7e40-86df-4e5ec63ad85f@oracle.com>

Hello,


On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
> Hi,
>
> Cross-posting this review-thread on core-libs-dev and build-dev as this
> is a build change, but affects fdlibm which is core-libs.
>
> With JDK-8170153 optimization for fdlibm code has been turned on for
> ppc64 s390 and aarch64. This patch intends to turn it on on all arches
> on Linux. I've not observed any precision issues. Is there a good
> reason to not use -O3 -ffp-contract=off everywhere?
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>
> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>           - Currently running through submit repo.
>
> A simple micro benchmark from JDK-8170153[1] shows these numbers for
> StrictMath:
>
> Function      | before     | after
> ----------------------------------------------
> sin           | 0m33.382s  | 0m18.731s
> cos           | 0m31.562s  | 0m18.796s
> tan           | 0m33.657s  | 0m21.093s
> atan          | 0m5.714s   | 0m4.902s
> log           | 0m6.212s   | 0m4.439s
> log10         | 0m7.946s   | 0m5.543s
> sqrt          | 0m0.481s   | 0m0.449s
> cbrt          | 0m5.295s   | 0m5.214s
> tanh          | 0m1.404s   | 0m1.307s
> log1p         | 0m6.457s   | 0m5.131s
> IEEEremainder | 0m10.629s  | 0m6.048s
> atan2         | 0m8.037s   | 0m5.668s
> hypot         | 0m2.171s   | 0m2.147s
>
>

Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), 
and exp (JDK-8139688), have been ported to Java as of JDK 9. The sqrt 
method is commonly handled as an intrinsic.

Testing that was not geared toward finding precision/rounding issues 
would be unlikely to find them.

I don't see the sources of the microbenchmark in JDK-8170153.

Cheers,

-Joe

From merkel05 at gmail.com  Wed Sep  5 19:22:53 2018
From: merkel05 at gmail.com (Sergey)
Date: Wed, 5 Sep 2018 21:22:53 +0200
Subject: [PATCH] Simplification of TreeMap
In-Reply-To: <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
 <7c89fc87-b612-9c23-cb60-eb34e9212a1e@fiolino.de>
 <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>
Message-ID: <CAPpfMiWp0pS1+GHdki=kK0RgtVX=vKkD-Ue3J6WU9N-Rfibc7Q@mail.gmail.com>

Hi Sergey,

Michael might correct me if I?ve missed something, but
problem with your test case is that you?re serializing already
patched version. That makes sense if you want to test current
behavior. However the case you truly want to test is how your
patched TreeMap deserializes pre-patched TreeMaps.

What you have currently just tests if patched map could be
deserialized without any problems.

Cheers,
su -

On Wed, 5 Sep 2018 at 20:30, ?????? ??????? <sergei.tsypanov at yandex.ru>
wrote:

> Hi Michael,
>
> thanks for pointing out this serialization concern, I didn't think about
> it at all.
>
> I've wrote a simple test for serialization of patched TreeMap and it works
> without errors for both no-args constructor and constructor with comparator:
>
> public class TreeMapSerialization {
>     public static void main(String[] args) throws Exception {
>         TreeMap<Integer, String> serialized = new
> TreeMap<>(Comparator.reverseOrder());
>         serialized.put(1, "1");
>         serialized.put(2, "2");
>
>         ByteArrayOutputStream baos = new ByteArrayOutputStream();
>         ObjectOutputStream oos = new ObjectOutputStream(baos);
>
>         oos.writeObject(serialized);
>         oos.flush();
>         baos.flush();
>         oos.close();
>         baos.close();
>
>         ByteArrayInputStream bais = new
> ByteArrayInputStream(baos.toByteArray());
>         ObjectInputStream ois = new ObjectInputStream(bais);
>
>         TreeMap<Integer, String> deserialized = (TreeMap<Integer, String>)
> ois.readObject();
>         deserialized.put(3, "3");
>
>         System.out.println(deserialized);
>     }
> }
>
>
> I hope I don't miss anything, so there shouldn't be any serialization
> issues.
>
> Regards,
> Sergey Tsypanov
>

From gromero at linux.vnet.ibm.com  Wed Sep  5 19:43:21 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 5 Sep 2018 16:43:21 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <8ac7400d-00af-7e40-86df-4e5ec63ad85f@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <8ac7400d-00af-7e40-86df-4e5ec63ad85f@oracle.com>
Message-ID: <5f5c91ee-4cd1-8db6-0344-24bfa585778d@linux.vnet.ibm.com>

Hello,

On 09/05/2018 04:15 PM, joe darcy wrote:
> Hello,
> 
> 
> On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
>> Hi,
>>
>> Cross-posting this review-thread on core-libs-dev and build-dev as this
>> is a build change, but affects fdlibm which is core-libs.
>>
>> With JDK-8170153 optimization for fdlibm code has been turned on for
>> ppc64 s390 and aarch64. This patch intends to turn it on on all arches
>> on Linux. I've not observed any precision issues. Is there a good
>> reason to not use -O3 -ffp-contract=off everywhere?
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8210416
>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>>
>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>> ????????? - Currently running through submit repo.
>>
>> A simple micro benchmark from JDK-8170153[1] shows these numbers for
>> StrictMath:
>>
>> Function????? | before???? | after
>> ----------------------------------------------
>> sin?????????? | 0m33.382s? | 0m18.731s
>> cos?????????? | 0m31.562s? | 0m18.796s
>> tan?????????? | 0m33.657s? | 0m21.093s
>> atan????????? | 0m5.714s?? | 0m4.902s
>> log?????????? | 0m6.212s?? | 0m4.439s
>> log10???????? | 0m7.946s?? | 0m5.543s
>> sqrt????????? | 0m0.481s?? | 0m0.449s
>> cbrt????????? | 0m5.295s?? | 0m5.214s
>> tanh????????? | 0m1.404s?? | 0m1.307s
>> log1p???????? | 0m6.457s?? | 0m5.131s
>> IEEEremainder | 0m10.629s? | 0m6.048s
>> atan2???????? | 0m8.037s?? | 0m5.668s
>> hypot???????? | 0m2.171s?? | 0m2.147s
>>
>>
> 
> Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), and exp (JDK-8139688), have been ported to Java as of JDK 9. The sqrt method is commonly handled as an intrinsic.
> 
> Testing that was not geared toward finding precision/rounding issues would be unlikely to find them.
> 
> I don't see the sources of the microbenchmark in JDK-8170153.

The microbench can be found on the first email I sent discussing that issue on Power.
Check it at the end, but there is nothing special in there:

http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-November/002738.html

There is also some discussing on the formal RFR:

http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-November/002751.html

Severin, the precision issues were quite conspicuous on Power when -O3 was turned on.
There are some discussions about it in the threads above IIRC. SAP helped to test the
change against additional tests, like TCK.

HTH.


Best regards,
Gustavo
  
> Cheers,
> 
> -Joe
> 


From roger.riggs at oracle.com  Wed Sep  5 20:07:52 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 5 Sep 2018 16:07:52 -0400
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: <1bd50a3e-724e-5eb3-0ddb-226066e61e70@oracle.com>

Hi Jim,

Overall it looks fine. Some quibbles on the wording and the test.


The spec for the align() and align(n) methods in String.java show a 
possibly misleading inconsistency.
The first line says:

    Removes vertical and horizontal white space margins.

But later align() says:

    Trailing spaces are  preserved.

The former implies all 4 margins but then it seems only to apply to 3 of 
the 4.? (top, left, bottom).
I'm not sure if there some wording that can clear that up in the first line.


AlignIndent.java:

 ?- Line 28: this test should not need /othervm nor the explicit @compile

 ?- There should be tests of align(n) with negative values.

 ?- The for for for for structure doesn't follow the style guide.


Thanks, Roger

(Sorry for the duplicates, I missed core-libs the first time)

On 8/29/18 10: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
>


From naoto.sato at oracle.com  Wed Sep  5 21:10:45 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 5 Sep 2018 14:10:45 -0700
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <35c46503-afea-50af-2f93-4ab3e447ba2b@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
 <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
 <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>
 <18c083fe-e22e-be08-97c6-d8a7dc02e68b@oracle.com>
 <35c46503-afea-50af-2f93-4ab3e447ba2b@oracle.com>
Message-ID: <4807130c-9273-43d5-165a-9ad9905592a7@oracle.com>

Hi Roger,

I updated the fix to share the zone only if the sharedZone is true. Here 
is the updated webrev:

http://cr.openjdk.java.net/~naoto/8210142/webrev.01/

Naoto

On 9/5/18 7:07 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> That sounds like a test issue.? I would not expect a cloned Calendar or 
> TimeZone to have a different hashCode.
> None of the fields involved in the hashCode/equals should be different. 
> (Or I'm missing something about them).
> 
> Thanks, Roger
> 
> 
> On 9/4/18 5:19 PM, Naoto Sato wrote:
>> Hi Roger,
>>
>> I tentatively tried to return a shared zone within a cloned Calendar. 
>> One test failed: java/util/Calendar/CalendarRegression.Test4136399, 
>> where it makes sure that the cloned Calendar object hash code should 
>> be different for the better distribution. Although the comment does 
>> not reflect the current implementation (getTimeZone() returning cloned 
>> zone), the intention here seems to have the better hash distribution 
>> for cloned objects.
>>
>> Naoto
>>
>> On 9/4/18 1:41 PM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> That access via reflection is going to go away sometime; so I'm not 
>>> too concerned about
>>> maintaining compatibility of the internal implementation.
>>> I think I'd rather see the memory savings, however small.
>>> Let see if anyone else has a recommendation.
>>>
>>> Roger
>>>
>>>
>>> On 9/4/18 4:12 PM, Naoto Sato wrote:
>>>> Hi Roger,
>>>>
>>>> Yes, I considered that too, but did not change the behavior and just 
>>>> to maintain the field consistent. I agree that it would not be 
>>>> observable via the public Calendar API, but some apps (like how the 
>>>> submitter found it) may be doing something using reflection.
>>>>
>>>> Naoto
>>>>
>>>> On 9/4/18 12:31 PM, Roger Riggs wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> The spec for clone doesn't say whether the clone should share or 
>>>>> not share the TimeZone.
>>>>> Did you consider that if sharedZone was true , *not* to clone the 
>>>>> TimeZone?
>>>>> It would still get cloned when requested from getTimeZone().
>>>>>
>>>>> This does seem somewhat safer not to change the cloning behavior 
>>>>> but I don't think the behavior would be observable.
>>>>>
>>>>> The current code and test is fine, except for reducing the 
>>>>> potential for sharing the TimeZone.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>>>>>
>>>>>> The proposed fix is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>>>>>
>>>>>> The fix is a simple one line change, which is to make the 
>>>>>> sharedZone field consistent with the cloned TimeZone instance in 
>>>>>> Calendar.clone().
>>>>>>
>>>>>> Naoto
>>>>>
>>>
> 

From igor.ignatyev at oracle.com  Wed Sep  5 21:32:17 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 5 Sep 2018 14:32:17 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
Message-ID: <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>

Hi JC,

thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion.

I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern.

incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html

Thanks,
-- Igor

> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com> wrote:
> 
> Hi Igor,
> 
> I reviewed the webrev but I noticed two things:
> 
> - Small nit:
>   - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html>
>      - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then?
> 
> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html>
>   - Seems we could refactor a bit this no?
>      - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized:
> 
> class TaskStream {
>    private final ByteArrayOutputStream buffer;
>    private Future<Void> task;
> 
>    public TaskStream(InputStream stream) {
>       buffer = new ByteArrayOutputStream();
>       task = new StreamPumper(stream, buffer).process();
>    }
> 
>     public String getBuffer() {
>       try {
>         task.get();
>         return buffer.toString();
>       } catch (InterruptedException e) {
>         Thread.currentThread().interrupt();
>         throw new OutputBufferException(e);
>       } catch (ExecutionException | CancellationException e) {
>         throw new OutputBufferException(e);
>       }
>     }
> }
> +  class LazyOutputBuffer implements OutputBuffer {
> +    private final TaskStream stderr;
> +    private final TaskStream stdout;
> +    private final Process p;
> +
> +    private LazyOutputBuffer(Process p) {
> +      this.p = p;
> +      stderr = new TaskStream(p.getInputStream());
> +      stdout = new TaskStream(p.getErrorStream());
> +    }
> +
> +    @Override
> +    public String getStdout() {
> +      return stdout.getBuffer();
> +    }
> 
> +    @Override
> +    public String getStderr() {
> +       return stderr.getBuffer()
> +    }
> 
> I think it is more clear, what do you think?
> 
> Apart from those two elements, it looks good to me :), nice refactor!
> Jc
> 
> 
> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
> > 2375 lines changed: 322 ins; 1662 del; 391 mod
> 
> Hi all,
> 
> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process?
> 
> there were a few differences b/w implementations which are addressed by the patch:
>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method
>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them.
>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest.
> 
> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible.  
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
> testing: tier1-tier3 + :jdk_svc
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 <https://bugs.openjdk.java.net/browse/JDK-8210112>
> 
> Thanks,
> -- Igor 
> 
> 
> 
> -- 
> 
> Thanks,
> Jc


From david.holmes at oracle.com  Wed Sep  5 21:32:50 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 6 Sep 2018 07:32:50 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
Message-ID: <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>

Hi Severin,

Might as well raise this here too as it's really a build philosophy 
issue. Shouldn't flags like -ffp-contract=off (and the existing AIX 
-qfloat=nomaf) be toolchain specific rather than platform specific?

Thanks,
David

On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> Hi,
> 
> Cross-posting this review-thread on core-libs-dev and build-dev as this
> is a build change, but affects fdlibm which is core-libs.
> 
> With JDK-8170153 optimization for fdlibm code has been turned on for
> ppc64 s390 and aarch64. This patch intends to turn it on on all arches
> on Linux. I've not observed any precision issues. Is there a good
> reason to not use -O3 -ffp-contract=off everywhere?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> 
> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>           - Currently running through submit repo.
> 
> A simple micro benchmark from JDK-8170153[1] shows these numbers for
> StrictMath:
> 
> Function      | before     | after
> ----------------------------------------------
> sin           | 0m33.382s  | 0m18.731s
> cos           | 0m31.562s  | 0m18.796s
> tan           | 0m33.657s  | 0m21.093s
> atan          | 0m5.714s   | 0m4.902s
> log           | 0m6.212s   | 0m4.439s
> log10         | 0m7.946s   | 0m5.543s
> sqrt          | 0m0.481s   | 0m0.449s
> cbrt          | 0m5.295s   | 0m5.214s
> tanh          | 0m1.404s   | 0m1.307s
> log1p         | 0m6.457s   | 0m5.131s
> IEEEremainder | 0m10.629s  | 0m6.048s
> atan2         | 0m8.037s   | 0m5.668s
> hypot         | 0m2.171s   | 0m2.147s
> 
> Thoughts?
> 
> Thanks,
> Severin
> 
> 

From jcbeyler at google.com  Wed Sep  5 21:59:01 2018
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 5 Sep 2018 14:59:01 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
Message-ID: <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>

Hi Igor,

I like this much better! A few more comments:

-
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html
  -> If the shouldMatch call fails, it throws an exception, why not just
let that fail test, why are you catching and then rethrowing (like you do
for
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html
)

-
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html
   There is now only a 1-liner for this method and it is called only once,
should we inline and remove the method?

- Same for (we could inline):
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html

-
http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html
    "There is no lines" -> "There are no lines"
    - What is the advantage of having the return at all now for the
shouldMatch methods, if it fails it throws, the test fails; otherwise it
doesn't return anything, the test can move on, no? I saw no moment when you
get the return to do something more with it

Thanks for the incremental webrev, that made looking at the changes so much
easier!
Jc

On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> Hi JC,
>
> thanks for reviewing this! I agree w/ both your comments and have updated
> the code very similarly to your suggestion.
>
> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method
> family is a bit different from other should* (and strange), besides
> checking that the lines match the pattern, shouldMatchByLine methods do not
> check that it's greater than zero and return number of matched lines
> instead. however all users of these methods do check that the return
> results is non zero. I have updated these methods to check that there are
> lines to match and updated all their users correspondingly. Doing that, I
> also made some harmless refactoring, like moving Pattern::compile from
> loops, using "\R" as end-of-line pattern.
>
> incremental webrev:
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html
>
> Thanks,
> -- Igor
>
> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com> wrote:
>
> Hi Igor,
>
> I reviewed the webrev but I noticed two things:
>
> - Small nit:
>   - In
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html
>      - I thought we don't have to flush as the stream gets closed and by
> closing flushes the stream, isn't that redundant then?
>
> -
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html
>   - Seems we could refactor a bit this no?
>      - If we put the Future and ByteArrayOutputStream in a separate class
> (ex TaskStream), then the constructor and the getters could be factorized:
>
> class TaskStream {
>    private final ByteArrayOutputStream buffer;
>    private Future<Void> task;
>
>    public TaskStream(InputStream stream) {
>       buffer = new ByteArrayOutputStream();
>       task = new StreamPumper(stream, buffer).process();
>    }
>
>     public String getBuffer() {
>       try {
>         task.get();
>         return buffer.toString();
>       } catch (InterruptedException e) {
>         Thread.currentThread().interrupt();
>         throw new OutputBufferException(e);
>       } catch (ExecutionException | CancellationException e) {
>         throw new OutputBufferException(e);
>       }
>     }
> }
>
> +  class LazyOutputBuffer implements OutputBuffer {
>
> +    private final TaskStream stderr;
>
> +    private final TaskStream stdout;
>
> +    private final Process p;++    private LazyOutputBuffer(Process p) {+      this.p = p;
>
> +      stderr = new TaskStream(p.getInputStream());
>
> +      stdout = new TaskStream(p.getErrorStream());+    }++    @Override+    public String getStdout() {
>
> +      return stdout.getBuffer();
>
> +    }+    @Override+    public String getStderr() {
>
> +       return stderr.getBuffer()+    }
>
>
> I think it is more clear, what do you think?
>
>
> Apart from those two elements, it looks good to me :), nice refactor!
>
> Jc
>
>
>
> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com>
> wrote:
>
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
>> > 2375 lines changed: 322 ins; 1662 del; 391 mod
>>
>> Hi all,
>>
>> could you please review the patch which removes
>> jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages
>> w/ corresponding classes from jdk.test.lib.process?
>>
>> there were a few differences b/w implementations which are addressed by
>> the patch:
>>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String)
>> method
>>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any
>> purposes, while j.t.OutputBuffer provided lazy access to a process's cout,
>> cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface
>> w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated
>> j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of
>> storing them.
>>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but
>> j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests
>> which really depend on absence of '-cp' and updated them to create
>> ProcessBuilder directly, namely JavaClassPathTest and
>> AppendToClassPathModuleTest.
>>
>> the rest of the patch is straightforward change of used classes w/ adding
>> @library /test/lib if necessary and removing @library /lib/testlibrary if
>> possible.
>>
>> webrev:
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
>> testing: tier1-tier3 + :jdk_svc
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112
>>
>> Thanks,
>> -- Igor
>>
>>
>
> --
>
> Thanks,
> Jc
>
>
>

-- 

Thanks,
Jc

From david.holmes at oracle.com  Wed Sep  5 22:00:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 6 Sep 2018 08:00:40 +1000
Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
In-Reply-To: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
Message-ID: <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com>

Hi Magnus,

On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
> When I removed (mostly) all mapfiles for the JDK libraries, building of 
> libjsig started failing on Solaris, and that part was backed out.
> 
> Here's a new, and improved solution to remove the mapfile for libjsig, 
> even on Solaris.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 

Why are the forward declarations Solaris-only when the actual function 
definitions add JNIEXPORT unconditionally?

   37  * before including signal.h */
   38 #include "sys/signal.h"

Why do we need to include sys/signal.h rather than just (the existing) 
signal.h?

Thanks,
David

> 
> /Magnus
> 

From magnus.ihse.bursie at oracle.com  Wed Sep  5 22:13:57 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 6 Sep 2018 00:13:57 +0200
Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
In-Reply-To: <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com>
References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
 <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com>
Message-ID: <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com>


> 6 sep. 2018 kl. 00:00 skrev David Holmes <david.holmes at oracle.com>:
> 
> Hi Magnus,
> 
>> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
>> When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out.
>> Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01
> 
> Why are the forward declarations Solaris-only when the actual function definitions add JNIEXPORT unconditionally?

No other toolchain has a problem when the definition of the functions adds JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration. 

It's certainly possible to do it for the other platforms, but it's not needed and I thought it didn't add anything to do it for all platforms. This way it's clear that the solstudio compiler is an anomaly. 

> 
>  37  * before including signal.h */
>  38 #include "sys/signal.h"
> 
> Why do we need to include sys/signal.h rather than just (the existing) signal.h?

Since it includes the definition of the sigaction struct that is needed for the sigaction() prototype. (signal.h includes sys/signal.h for type definitions)

/Magnus

> 
> Thanks,
> David
> 
>> /Magnus


From igor.ignatyev at oracle.com  Wed Sep  5 22:20:35 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 5 Sep 2018 15:20:35 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
 <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
Message-ID: <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>

Hi JC,


> On Sep 5, 2018, at 2:59 PM, JC Beyler <jcbeyler at google.com> wrote:
> 
> Hi Igor,
> 
> I like this much better! A few more comments:
> 
> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html>
>   -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>)
just to follow the style used by this tests, e.g.

>   54         try {
>   55             output.shouldContain(stdout);
>   56             output.stdoutShouldContain(stdout);
>   57             output.shouldContain(stderr);
>   58             output.stderrShouldContain(stderr);
>   59         } catch (RuntimeException e) {
>   60             throw new Exception("shouldContain() failed", e);
>   61         }

>   86         try {
>   87             output.shouldNotContain(nonExistingString);
>   88             output.stdoutShouldNotContain(nonExistingString);
>   89             output.stderrShouldNotContain(nonExistingString);
>   90         } catch (RuntimeException e) {
>   91             throw new Exception("shouldNotContain() failed", e);
>   92         }
>   93 


> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>
>    There is now only a 1-liner for this method and it is called only once, should we inline and remove the method?

we can, but I ain't sure we should. from my point of view

  80         output.shouldHaveExitValue(0);
  81         output.shouldContain("sun.tools.jcmd.JCmd");
  82         matchListedProcesses(output);
is a bit easier to understand than
  80         output.shouldHaveExitValue(0);
  81         output.shouldContain("sun.tools.jcmd.JCmd");
  82         output.shouldMatchByLine(JCMD_LIST_REGEX);

however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses.

> - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html>same here

> 
> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html>
>     "There is no lines" -> "There are no lines"
fixed. thanks for spotting.

>     - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it
OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this.


> Thanks for the incremental webrev, that made looking at the changes so much easier!

here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html>

-- Igor
> Jc
> 
> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
> Hi JC,
> 
> thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion.
> 
> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern.
> 
> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html>
> 
> Thanks,
> -- Igor
> 
>> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com <mailto:jcbeyler at google.com>> wrote:
>> 
>> Hi Igor,
>> 
>> I reviewed the webrev but I noticed two things:
>> 
>> - Small nit:
>>   - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html>
>>      - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then?
>> 
>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html>
>>   - Seems we could refactor a bit this no?
>>      - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized:
>> 
>> class TaskStream {
>>    private final ByteArrayOutputStream buffer;
>>    private Future<Void> task;
>> 
>>    public TaskStream(InputStream stream) {
>>       buffer = new ByteArrayOutputStream();
>>       task = new StreamPumper(stream, buffer).process();
>>    }
>> 
>>     public String getBuffer() {
>>       try {
>>         task.get();
>>         return buffer.toString();
>>       } catch (InterruptedException e) {
>>         Thread.currentThread().interrupt();
>>         throw new OutputBufferException(e);
>>       } catch (ExecutionException | CancellationException e) {
>>         throw new OutputBufferException(e);
>>       }
>>     }
>> }
>> +  class LazyOutputBuffer implements OutputBuffer {
>> +    private final TaskStream stderr;
>> +    private final TaskStream stdout;
>> +    private final Process p;
>> +
>> +    private LazyOutputBuffer(Process p) {
>> +      this.p = p;
>> +      stderr = new TaskStream(p.getInputStream());
>> +      stdout = new TaskStream(p.getErrorStream());
>> +    }
>> +
>> +    @Override
>> +    public String getStdout() {
>> +      return stdout.getBuffer();
>> +    }
>> 
>> +    @Override
>> +    public String getStderr() {
>> +       return stderr.getBuffer()
>> +    }
>> 
>> I think it is more clear, what do you think?
>> 
>> Apart from those two elements, it looks good to me :), nice refactor!
>> Jc
>> 
>> 
>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>> > 2375 lines changed: 322 ins; 1662 del; 391 mod
>> 
>> Hi all,
>> 
>> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process?
>> 
>> there were a few differences b/w implementations which are addressed by the patch:
>>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method
>>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them.
>>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest.
>> 
>> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible.  
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>> testing: tier1-tier3 + :jdk_svc
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 <https://bugs.openjdk.java.net/browse/JDK-8210112>
>> 
>> Thanks,
>> -- Igor 
>> 
>> 
>> 
>> -- 
>> 
>> Thanks,
>> Jc
> 
> 
> 
> -- 
> 
> Thanks,
> Jc


From david.holmes at oracle.com  Wed Sep  5 22:21:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 6 Sep 2018 08:21:27 +1000
Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
In-Reply-To: <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com>
References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com>
 <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com>
 <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com>
Message-ID: <3f8c70f8-53b8-efb4-518c-24f675d6fea5@oracle.com>

On 6/09/2018 8:13 AM, Magnus Ihse Bursie wrote:
> 
>> 6 sep. 2018 kl. 00:00 skrev David Holmes <david.holmes at oracle.com>:
>>
>> Hi Magnus,
>>
>>> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
>>> When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out.
>>> Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01
>>
>> Why are the forward declarations Solaris-only when the actual function definitions add JNIEXPORT unconditionally?
> 
> No other toolchain has a problem when the definition of the functions adds JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration.
> 
> It's certainly possible to do it for the other platforms, but it's not needed and I thought it didn't add anything to do it for all platforms. This way it's clear that the solstudio compiler is an anomaly.

Okay.

>>
>>   37  * before including signal.h */
>>   38 #include "sys/signal.h"
>>
>> Why do we need to include sys/signal.h rather than just (the existing) signal.h?
> 
> Since it includes the definition of the sigaction struct that is needed for the sigaction() prototype. (signal.h includes sys/signal.h for type definitions)

Doh! Of course.

Thanks,
David

> /Magnus
> 
>>
>> Thanks,
>> David
>>
>>> /Magnus
> 

From jcbeyler at google.com  Thu Sep  6 00:03:29 2018
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 5 Sep 2018 17:03:29 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
 <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
 <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>
Message-ID: <CAF9BGBywv09PaHy6N5FWT2aHfjWPVGYX8RwMEbMD0Wt6=VyUXg@mail.gmail.com>

Hi Igor,

Looks good to me then. I agree most are nits, personal preferences, and
just I noticed them as you were cleaning them up!

Awesome clean up :-)
Jc

On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> Hi JC,
>
>
> On Sep 5, 2018, at 2:59 PM, JC Beyler <jcbeyler at google.com> wrote:
>
> Hi Igor,
>
> I like this much better! A few more comments:
>
> -
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html
>   -> If the shouldMatch call fails, it throws an exception, why not just
> let that fail test, why are you catching and then rethrowing (like you do
> for
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html
> )
>
> just to follow the style used by this tests, e.g.
>
>   54         try {
>   55             output.shouldContain(stdout);
>   56             output.stdoutShouldContain(stdout);
>   57             output.shouldContain(stderr);
>   58             output.stderrShouldContain(stderr);
>   59         } catch (RuntimeException e) {
>   60             throw new Exception("shouldContain() failed", e);
>   61         }
>
>
>   86         try {
>   87             output.shouldNotContain(nonExistingString);
>   88             output.stdoutShouldNotContain(nonExistingString);
>   89             output.stderrShouldNotContain(nonExistingString);
>   90         } catch (RuntimeException e) {
>   91             throw new Exception("shouldNotContain() failed", e);
>   92         }
>   93
>
>
>
> -
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html
>    There is now only a 1-liner for this method and it is called only once,
> should we inline and remove the method?
>
>
> we can, but I ain't sure we should. from my point of view
>
>   80         output.shouldHaveExitValue(0);
>   81         output.shouldContain("sun.tools.jcmd.JCmd");
>   82         matchListedProcesses(output);
>
> is a bit easier to understand than
>
>   80         output.shouldHaveExitValue(0);
>   81         output.shouldContain("sun.tools.jcmd.JCmd");
>   82         output.shouldMatchByLine(JCMD_LIST_REGEX);
>
>
> however, I don't have strong preference here and if serviceability team
> wants, I can inline matchListedProcesses.
>
> - Same for (we could inline):
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html
>
> same here
>
>
> -
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html
>     "There is no lines" -> "There are no lines"
>
> fixed. thanks for spotting.
>
>     - What is the advantage of having the return at all now for the
> shouldMatch methods, if it fails it throws, the test fails; otherwise it
> doesn't return anything, the test can move on, no? I saw no moment when you
> get the return to do something more with it
>
> OutputAnalazyer is supposed to be a fluent interface, and in some cases
> you might find it used that way, so I'd prefer to have possibility to use
> these methods in a method chain, as w/ we already have for the the most of
> other should* method. I've fixed a few more should* methods to return this.
>
>
> Thanks for the incremental webrev, that made looking at the changes so
> much easier!
>
>
> here is the next one --
> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html
>
> -- Igor
>
> Jc
>
> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev <igor.ignatyev at oracle.com>
> wrote:
>
>> Hi JC,
>>
>> thanks for reviewing this! I agree w/ both your comments and have updated
>> the code very similarly to your suggestion.
>>
>> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method
>> family is a bit different from other should* (and strange), besides
>> checking that the lines match the pattern, shouldMatchByLine methods do not
>> check that it's greater than zero and return number of matched lines
>> instead. however all users of these methods do check that the return
>> results is non zero. I have updated these methods to check that there are
>> lines to match and updated all their users correspondingly. Doing that, I
>> also made some harmless refactoring, like moving Pattern::compile from
>> loops, using "\R" as end-of-line pattern.
>>
>> incremental webrev:
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html
>>
>> Thanks,
>> -- Igor
>>
>> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com> wrote:
>>
>> Hi Igor,
>>
>> I reviewed the webrev but I noticed two things:
>>
>> - Small nit:
>>   - In
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html
>>      - I thought we don't have to flush as the stream gets closed and by
>> closing flushes the stream, isn't that redundant then?
>>
>> -
>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html
>>   - Seems we could refactor a bit this no?
>>      - If we put the Future and ByteArrayOutputStream in a separate class
>> (ex TaskStream), then the constructor and the getters could be factorized:
>>
>> class TaskStream {
>>    private final ByteArrayOutputStream buffer;
>>    private Future<Void> task;
>>
>>    public TaskStream(InputStream stream) {
>>       buffer = new ByteArrayOutputStream();
>>       task = new StreamPumper(stream, buffer).process();
>>    }
>>
>>     public String getBuffer() {
>>       try {
>>         task.get();
>>         return buffer.toString();
>>       } catch (InterruptedException e) {
>>         Thread.currentThread().interrupt();
>>         throw new OutputBufferException(e);
>>       } catch (ExecutionException | CancellationException e) {
>>         throw new OutputBufferException(e);
>>       }
>>     }
>> }
>>
>> +  class LazyOutputBuffer implements OutputBuffer {
>>
>> +    private final TaskStream stderr;
>>
>> +    private final TaskStream stdout;
>>
>> +    private final Process p;++    private LazyOutputBuffer(Process p) {+      this.p = p;
>>
>> +      stderr = new TaskStream(p.getInputStream());
>>
>> +      stdout = new TaskStream(p.getErrorStream());+    }++    @Override+    public String getStdout() {
>>
>> +      return stdout.getBuffer();
>>
>> +    }+    @Override+    public String getStderr() {
>>
>> +       return stderr.getBuffer()+    }
>>
>>
>> I think it is more clear, what do you think?
>>
>>
>> Apart from those two elements, it looks good to me :), nice refactor!
>>
>> Jc
>>
>>
>>
>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com>
>> wrote:
>>
>>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
>>> > 2375 lines changed: 322 ins; 1662 del; 391 mod
>>>
>>> Hi all,
>>>
>>> could you please review the patch which removes
>>> jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages
>>> w/ corresponding classes from jdk.test.lib.process?
>>>
>>> there were a few differences b/w implementations which are addressed by
>>> the patch:
>>>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String)
>>> method
>>>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>>>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any
>>> purposes, while j.t.OutputBuffer provided lazy access to a process's cout,
>>> cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface
>>> w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated
>>> j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of
>>> storing them.
>>>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but
>>> j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests
>>> which really depend on absence of '-cp' and updated them to create
>>> ProcessBuilder directly, namely JavaClassPathTest and
>>> AppendToClassPathModuleTest.
>>>
>>> the rest of the patch is straightforward change of used classes w/
>>> adding @library /test/lib if necessary and removing @library
>>> /lib/testlibrary if possible.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html
>>> testing: tier1-tier3 + :jdk_svc
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112
>>>
>>> Thanks,
>>> -- Igor
>>>
>>>
>>
>> --
>>
>> Thanks,
>> Jc
>>
>>
>>
>
> --
>
> Thanks,
> Jc
>
>
>

-- 

Thanks,
Jc

From jai.forums2013 at gmail.com  Thu Sep  6 07:13:53 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 6 Sep 2018 12:43:53 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>


Hello Bernd,

Thank you for the review and sorry about the delayed response. Comments
inline.

On 29/08/18 4:26 PM, Bernd Eckenfels wrote:
> 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.

+     * @apiNote
+     * This method also provides a convenient way to create a fixed-size
      * list initialized to contain several elements:
      * <pre>
      *     List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");
      * </pre>
      *

My limited understanding of the @apiNote is that it is supposed to be
used for additional details of the API and/or its usage examples and the
javadoc itself (outside of the @apiNote) should be a specification of
the API. In this case, I moved that section to @apiNote since that part
appears to mention how/when to use that API in. Having said that, I can
move it out of @apiNote and let it stay the way it previously was, if
you and others feel that's the way to go.

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

I'm not too sure mentioning List.of() construct here will be useful, but
I do see why you mention that. I think the existing example does seem
like a useful usage example, irrespective of whether or not we decide to
have it in or outside of an @apiNote.

-Jaikiran


From jdk at fiolino.de  Thu Sep  6 07:27:01 2018
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Thu, 6 Sep 2018 09:27:01 +0200
Subject: [PATCH] Simplification of TreeMap
In-Reply-To: <CAPpfMiWp0pS1+GHdki=kK0RgtVX=vKkD-Ue3J6WU9N-Rfibc7Q@mail.gmail.com>
References: <4705141536088461@myt5-f1576e7b5bad.qloud-c.yandex.net>
 <7c89fc87-b612-9c23-cb60-eb34e9212a1e@fiolino.de>
 <14702991536172218@iva1-16f33c6a446b.qloud-c.yandex.net>
 <CAPpfMiWp0pS1+GHdki=kK0RgtVX=vKkD-Ue3J6WU9N-Rfibc7Q@mail.gmail.com>
Message-ID: <21c0bdf2-c0f0-7236-3e30-74f08f99e96b@fiolino.de>

Hi Sergey and Sergey ;),

that's totally correct! Serialization really is a beast sometimes, you
have to take care that instances that have been serialized even with
Java 1.2 still get deserialized correctly in the current version.

So it's not sufficient to only look at the constructors when the class
is Serializable. In the case of TreeMap, the only solutions I see are
either making 'comparator' mutable and setting it in readObject(), or
again always check for null values when accessing it - which would make
your idea rather useless. As Martin already mentioned, "if it's not
broken, don't fix it" - either option is not worth the change.

What would make sense is to remove valEquals() in favor of
Objects::equals, so at least a minor patch would remain. ;)

-Michael


Am 05.09.2018 um 21:22 schrieb Sergey:
> Hi Sergey,
> 
> Michael might correct me if I?ve missed something, but?
> problem with your test case is that you?re serializing already?
> patched version. That makes sense if you want to test current?
> behavior. However the case you truly want to test is how your
> patched TreeMap deserializes pre-patched TreeMaps.
> 
> What you have currently just tests if patched map could be
> deserialized without any problems.
> 
> Cheers,
> su -
> 
> On Wed, 5 Sep 2018 at 20:30, ?????? ??????? <sergei.tsypanov at yandex.ru
> <mailto:sergei.tsypanov at yandex.ru>> wrote:
> 
>     Hi Michael,
> 
>     thanks for pointing out this serialization concern, I didn't think
>     about it at all.
> 
>     I've wrote a simple test for serialization of patched TreeMap and it
>     works without errors for both no-args constructor and constructor
>     with comparator:
> 
>     public class TreeMapSerialization {
>     ? ? public static void main(String[] args) throws Exception {
>     ? ? ? ? TreeMap<Integer, String> serialized = new
>     TreeMap<>(Comparator.reverseOrder());
>     ? ? ? ? serialized.put(1, "1");
>     ? ? ? ? serialized.put(2, "2");
> 
>     ? ? ? ? ByteArrayOutputStream baos = new ByteArrayOutputStream();
>     ? ? ? ? ObjectOutputStream oos = new ObjectOutputStream(baos);
> 
>     ? ? ? ? oos.writeObject(serialized);
>     ? ? ? ? oos.flush();
>     ? ? ? ? baos.flush();
>     ? ? ? ? oos.close();
>     ? ? ? ? baos.close();
> 
>     ? ? ? ? ByteArrayInputStream bais = new
>     ByteArrayInputStream(baos.toByteArray());
>     ? ? ? ? ObjectInputStream ois = new ObjectInputStream(bais);
> 
>     ? ? ? ? TreeMap<Integer, String> deserialized = (TreeMap<Integer,
>     String>) ois.readObject();
>     ? ? ? ? deserialized.put(3, "3");
> 
>     ? ? ? ? System.out.println(deserialized);
>     ? ? }
>     }
> 
> 
>     I hope I don't miss anything, so there shouldn't be any
>     serialization issues.
> 
>     Regards,
>     Sergey Tsypanov
> 


From ecki at zusammenkunft.net  Thu Sep  6 07:54:47 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 6 Sep 2018 07:54:47 +0000
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>,
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
Message-ID: <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>

Yes you are right @apinote is aproperiate section (was confusing it with implnote).

Still think a ?literal specified list? is no longer a good (as in canonical) usecase for that method.

I used it in the past often to get a List for using toString() on it, but I guess even for that case List.of can be used instead now.

So @see List#of and let the reader figure out when to use them?

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

________________________________
Von: Jaikiran Pai <jai.forums2013 at gmail.com>
Gesendet: Donnerstag, September 6, 2018 9:13 AM
An: Bernd Eckenfels; core-libs-dev at openjdk.java.net
Betreff: Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList



Hello Bernd,

Thank you for the review and sorry about the delayed response. Comments inline.

On 29/08/18 4:26 PM, Bernd Eckenfels wrote:
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.


+     * @apiNote
+     * This method also provides a convenient way to create a fixed-size
      * list initialized to contain several elements:
      * <pre>
      *     List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");
      * </pre>
      *

My limited understanding of the @apiNote is that it is supposed to be used for additional details of the API and/or its usage examples and the javadoc itself (outside of the @apiNote) should be a specification of the API. In this case, I moved that section to @apiNote since that part appears to mention how/when to use that API in. Having said that, I can move it out of @apiNote and let it stay the way it previously was, if you and others feel that's the way to go.


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?

I'm not too sure mentioning List.of() construct here will be useful, but I do see why you mention that. I think the existing example does seem like a useful usage example, irrespective of whether or not we decide to have it in or outside of an @apiNote.

-Jaikiran


From xu.y.yin at oracle.com  Thu Sep  6 08:00:38 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 6 Sep 2018 16:00:38 +0800
Subject: [12] RFR 8042902: Test
 java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails
 intermittently
Message-ID: <96CB1C48-A4D6-4CBB-98FB-73A1BEFB42EF@oracle.com>

Please have a review for below minor change to test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java, thanks

The bug has a long history, so a quick summary and explanation here, the issue which caused test failure before 2016 should already been fixed, so this fix change is for new observed failures in 2018. I checked all failures happened on Mac OS platform.
The failure is weird that we got different value by call InetAddress.getHostName() on same address one after one in very short time, cannot make sure whether any network configuration change or Mac OS system caused the difference for multiple name reverse lookup, but from this test aspect, guess the focus on address serialization should be enough, so below fix change is simple, we will call InetAddress.getHostName() first to set holder() ?s hostname field in testAllNetworkInterfaces() before serialization test (as Chris Hegarty commented in 2014. And per Mark's comments, "display call was commented out as it was too verbose" so we just simple print hostname instead of get whole display call function back), then when we deserialized the address object and do comparison with original one later, getHostName() call will retrieve holder() ?s hostname value directly, that should eliminate the possible difference when doing name reverse lookup twice.

bug: https://bugs.openjdk.java.net/browse/JDK-8042902

changes:

diff -r b51d348698c2 test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
--- a/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Wed Sep 05 19:40:52 2018 -0700
+++ b/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Thu Sep 06 14:29:38 2018 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 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
@@ -192,6 +192,7 @@
                     System.err.println("Testing with " + iadr);
                     System.err.println(" scoped iface: "
                             + i6adr.getScopedInterface());
+                    System.err.println(" hostname: " + i6adr.getHostName());
                     testInet6AddressSerialization(i6adr, null);
                 }
             }

Regards,
Chris

From chris.hegarty at oracle.com  Thu Sep  6 08:05:33 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 6 Sep 2018 09:05:33 +0100
Subject: [12] RFR 8042902: Test
 java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails
 intermittently
In-Reply-To: <96CB1C48-A4D6-4CBB-98FB-73A1BEFB42EF@oracle.com>
References: <96CB1C48-A4D6-4CBB-98FB-73A1BEFB42EF@oracle.com>
Message-ID: <834D0942-5C31-49DB-9551-35A47C1873F1@oracle.com>


> On 6 Sep 2018, at 09:00, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Please have a review for below minor change to test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java, thanks
> 
> The bug has a long history, so a quick summary and explanation here, the issue which caused test failure before 2016 should already been fixed, so this fix change is for new observed failures in 2018. I checked all failures happened on Mac OS platform.
> The failure is weird that we got different value by call InetAddress.getHostName() on same address one after one in very short time, cannot make sure whether any network configuration change or Mac OS system caused the difference for multiple name reverse lookup, but from this test aspect, guess the focus on address serialization should be enough, so below fix change is simple, we will call InetAddress.getHostName() first to set holder() ?s hostname field in testAllNetworkInterfaces() before serialization test (as Chris Hegarty commented in 2014. And per Mark's comments, "display call was commented out as it was too verbose" so we just simple print hostname instead of get whole display call function back), then when we deserialized the address object and do comparison with original one later, getHostName() call will retrieve holder() ?s hostname value directly, that should eliminate the possible difference when doing name reverse lookup twice.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8042902
> 
> changes:
> 
> diff -r b51d348698c2 test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
> --- a/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Wed Sep 05 19:40:52 2018 -0700
> +++ b/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Thu Sep 06 14:29:38 2018 +0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 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
> @@ -192,6 +192,7 @@
>                     System.err.println("Testing with " + iadr);
>                     System.err.println(" scoped iface: "
>                             + i6adr.getScopedInterface());
> +                    System.err.println(" hostname: " + i6adr.getHostName());
>                     testInet6AddressSerialization(i6adr, null);
>                 }
>             }

Thanks Chris Y.    I think the change looks fine.

-Chris H.

From xu.y.yin at oracle.com  Thu Sep  6 08:11:21 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 6 Sep 2018 16:11:21 +0800
Subject: [12] RFR 8042902: Test
 java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails
 intermittently
In-Reply-To: <834D0942-5C31-49DB-9551-35A47C1873F1@oracle.com>
References: <96CB1C48-A4D6-4CBB-98FB-73A1BEFB42EF@oracle.com>
 <834D0942-5C31-49DB-9551-35A47C1873F1@oracle.com>
Message-ID: <F2E546D5-FA11-4AEC-8D5C-E0FBFA87851A@oracle.com>

Thank you, Chris H.  :)

Regards,
Chris Y.

> On 6 Sep 2018, at 4:05 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 6 Sep 2018, at 09:00, Chris Yin <xu.y.yin at oracle.com> wrote:
>> 
>> Please have a review for below minor change to test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java, thanks
>> 
>> The bug has a long history, so a quick summary and explanation here, the issue which caused test failure before 2016 should already been fixed, so this fix change is for new observed failures in 2018. I checked all failures happened on Mac OS platform.
>> The failure is weird that we got different value by call InetAddress.getHostName() on same address one after one in very short time, cannot make sure whether any network configuration change or Mac OS system caused the difference for multiple name reverse lookup, but from this test aspect, guess the focus on address serialization should be enough, so below fix change is simple, we will call InetAddress.getHostName() first to set holder() ?s hostname field in testAllNetworkInterfaces() before serialization test (as Chris Hegarty commented in 2014. And per Mark's comments, "display call was commented out as it was too verbose" so we just simple print hostname instead of get whole display call function back), then when we deserialized the address object and do comparison with original one later, getHostName() call will retrieve holder() ?s hostname value directly, that should eliminate the possible difference when doing name reverse lookup twice.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8042902
>> 
>> changes:
>> 
>> diff -r b51d348698c2 test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
>> --- a/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Wed Sep 05 19:40:52 2018 -0700
>> +++ b/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java	Thu Sep 06 14:29:38 2018 +0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 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
>> @@ -192,6 +192,7 @@
>>                    System.err.println("Testing with " + iadr);
>>                    System.err.println(" scoped iface: "
>>                            + i6adr.getScopedInterface());
>> +                    System.err.println(" hostname: " + i6adr.getHostName());
>>                    testInet6AddressSerialization(i6adr, null);
>>                }
>>            }
> 
> Thanks Chris Y.    I think the change looks fine.
> 
> -Chris H.


From sgehwolf at redhat.com  Thu Sep  6 10:12:22 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 06 Sep 2018 12:12:22 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
Message-ID: <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>

Hi David,

On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:
> Hi Severin,
> 
> Might as well raise this here too as it's really a build philosophy 
> issue. Shouldn't flags like -ffp-contract=off (and the existing AIX 
> -qfloat=nomaf) be toolchain specific rather than platform specific?

Looks like Clang has -ffp-contract:
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract

Is there any other (supported) toolchain other than gcc and clang on
linux? As for AIX I suppose there is only on supported toolchain?

Thanks,
Severin

> Thanks,
> David
> 
> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Cross-posting this review-thread on core-libs-dev and build-dev as
> > this
> > is a build change, but affects fdlibm which is core-libs.
> > 
> > With JDK-8170153 optimization for fdlibm code has been turned on
> > for
> > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > arches
> > on Linux. I've not observed any precision issues. Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> > 
> > Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> > webrev: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > 
> > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> >           - Currently running through submit repo.
> > 
> > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > for
> > StrictMath:
> > 
> > Function      | before     | after
> > ----------------------------------------------
> > sin           | 0m33.382s  | 0m18.731s
> > cos           | 0m31.562s  | 0m18.796s
> > tan           | 0m33.657s  | 0m21.093s
> > atan          | 0m5.714s   | 0m4.902s
> > log           | 0m6.212s   | 0m4.439s
> > log10         | 0m7.946s   | 0m5.543s
> > sqrt          | 0m0.481s   | 0m0.449s
> > cbrt          | 0m5.295s   | 0m5.214s
> > tanh          | 0m1.404s   | 0m1.307s
> > log1p         | 0m6.457s   | 0m5.131s
> > IEEEremainder | 0m10.629s  | 0m6.048s
> > atan2         | 0m8.037s   | 0m5.668s
> > hypot         | 0m2.171s   | 0m2.147s
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > 


From sgehwolf at redhat.com  Thu Sep  6 10:21:18 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 06 Sep 2018 12:21:18 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <8ac7400d-00af-7e40-86df-4e5ec63ad85f@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <8ac7400d-00af-7e40-86df-4e5ec63ad85f@oracle.com>
Message-ID: <63a71e81263a18dbc35e62e441501eb7944ae394.camel@redhat.com>

Hi Joe,

On Wed, 2018-09-05 at 12:15 -0700, joe darcy wrote:
> On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Cross-posting this review-thread on core-libs-dev and build-dev as
> > this
> > is a build change, but affects fdlibm which is core-libs.
> > 
> > With JDK-8170153 optimization for fdlibm code has been turned on
> > for
> > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > arches
> > on Linux. I've not observed any precision issues. Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> > 
> > Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> > webrev: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > 
> > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> >           - Currently running through submit repo.
> > 
> > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > for
> > StrictMath:
> > 
> > Function      | before     | after
> > ----------------------------------------------
> > sin           | 0m33.382s  | 0m18.731s
> > cos           | 0m31.562s  | 0m18.796s
> > tan           | 0m33.657s  | 0m21.093s
> > atan          | 0m5.714s   | 0m4.902s
> > log           | 0m6.212s   | 0m4.439s
> > log10         | 0m7.946s   | 0m5.543s
> > sqrt          | 0m0.481s   | 0m0.449s
> > cbrt          | 0m5.295s   | 0m5.214s
> > tanh          | 0m1.404s   | 0m1.307s
> > log1p         | 0m6.457s   | 0m5.131s
> > IEEEremainder | 0m10.629s  | 0m6.048s
> > atan2         | 0m8.037s   | 0m5.668s
> > hypot         | 0m2.171s   | 0m2.147s
> > 
> > 
> 
> Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), 
> and exp (JDK-8139688), have been ported to Java as of JDK 9. The sqrt 
> method is commonly handled as an intrinsic.

OK thanks. Since ppc64/s390x/aarch64 uses this already on Linux do you
anticipate the same being applied to x86/x86_64 causing issues (modulo
compiler bugs of course)?

> Testing that was not geared toward finding precision/rounding issues 
> would be unlikely to find them.

Would running the TCK be geared towards precision/rounding issues? I
could ask someone to run the TCK on a test build on x86_64/x86 to find
out.

> I don't see the sources of the microbenchmark in JDK-8170153.

https://github.com/gromero/strictmath/

Thanks,
Severin


From andrew_m_leonard at uk.ibm.com  Thu Sep  6 10:29:27 2018
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Thu, 6 Sep 2018 11:29:27 +0100
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <518B1A25-286A-45DB-83EB-708772CABF5A@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>
 <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com>
 <OF6762A821.CDC4AB6E-ON802582FE.003784EE-802582FE.0037F0E9@notes.na.collabserv.com>
 <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com>
Message-ID: <OF15E5D06F.FAC2B5D9-ON80258300.00395D6C-80258300.00399B80@notes.na.collabserv.com>

Thanks Magnus,

Hi Goetz, we have agreement from both library owners, so I think we're 
good now?
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:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>
Cc:     Brian Burkhalter <brian.burkhalter at oracle.com>, 2d-dev 
<2d-dev at openjdk.java.net>, build-dev <build-dev at openjdk.java.net>, 
core-libs-dev <core-libs-dev at openjdk.java.net>, "Lindenmaier, Goetz" 
<goetz.lindenmaier at sap.com>, Philip Race <philip.race at oracle.com>
Date:   04/09/2018 16:41
Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux



Looks good to me. 

/Magnus

4 sep. 2018 kl. 12:11 skrev Andrew Leonard <andrew_m_leonard at uk.ibm.com>:

Hi Brian/Goetz, 
Yes, that seems sensible. I have created a new webrev with fdlibm compiler 
option disabled, and mediaLib code fixed: 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ 
I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. 

Are we good to go? 
Thanks 
Andrew 

hg export: 
# HG changeset patch 
# User aleonard 
# Date 1536055438 -3600 
#      Tue Sep 04 11:03:58 2018 +0100 
# Node ID c2523f285c503e8f82f1212b38de1cb54093255e 
# Parent  3ee91722550680c18b977f0e00b1013323b5c9ef 
8209786: JDK12 fails to build on s390x with gcc 7.3 

diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk 
--- a/make/lib/CoreLibraries.gmk        Tue Sep 04 14:47:55 2018 +0800 
+++ b/make/lib/CoreLibraries.gmk        Tue Sep 04 11:03:58 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, \ 
diff -r 3ee917225506 -r c2523f285c50 
src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c 
--- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 14:47:55 2018 +0800 
+++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 11:03:58 2018 +0100 
@@ -1,5 +1,5 @@ 
 /* 
- * Copyright (c) 2003, 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 
@@ -259,18 +259,18 @@ 
       } 
  
 #ifdef _LITTLE_ENDIAN 
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
       ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ 
emask); 
  
 #else /* _NO_LONGLONG */ 
  
 #ifdef _LITTLE_ENDIAN 
-      mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 
8); 
+      mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
 #else 
-      mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
+      mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
  
       ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | 
(((mlib_u64*)da)[0] &~ emask); 
@@ -395,9 +395,9 @@ 
       } 
  
 #ifdef _LITTLE_ENDIAN 
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
       ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); 

  
@@ -413,9 +413,9 @@ 
       } 
  
 #ifdef _LITTLE_ENDIAN 
-      emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
+      emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
 #else 
-      emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
+      emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
       ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); 
  
@@ -565,9 +565,9 @@ 
       } 
  
 #ifdef _LITTLE_ENDIAN 
-      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
       da[0] = (dd & emask) | (da[0] &~ emask); 
     } 







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:        Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> 
Cc:        Andrew Leonard <andrew_m_leonard at uk.ibm.com>, "Lindenmaier, 
Goetz" <goetz.lindenmaier at sap.com>, 2d-dev <2d-dev at openjdk.java.net>, 
build-dev <build-dev at openjdk.java.net>, core-libs-dev <
core-libs-dev at openjdk.java.net>, Philip Race <philip.race at oracle.com> 
Date:        31/08/2018 15:44 
Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux 




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 



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 goetz.lindenmaier at sap.com  Thu Sep  6 11:02:14 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 6 Sep 2018 11:02:14 +0000
Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
 zLinux
In-Reply-To: <OF15E5D06F.FAC2B5D9-ON80258300.00395D6C-80258300.00399B80@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>
 <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com>
 <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com>
 <OF6762A821.CDC4AB6E-ON802582FE.003784EE-802582FE.0037F0E9@notes.na.collabserv.com>
 <518B1A25-286A-45DB-83EB-708772CABF5A@oracle.com>
 <OF15E5D06F.FAC2B5D9-ON80258300.00395D6C-80258300.00399B80@notes.na.collabserv.com>
Message-ID: <df16ae49cb1d4032a77e7e44ecd44ab3@sap.com>

Yes, that's fine. 

I can sponsor it tomorrow. I'm not in the office today.

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Sent: Donnerstag, 6. September 2018 12:29
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: 2d-dev <2d-dev at openjdk.java.net>; Brian Burkhalter
> <brian.burkhalter at oracle.com>; build-dev <build-dev at openjdk.java.net>; core-
> libs-dev <core-libs-dev at openjdk.java.net>; Philip Race
> <philip.race at oracle.com>
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> Thanks Magnus,
> 
> Hi Goetz, we have agreement from both library owners, so I think we're good
> now?
> 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:        Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> Cc:        Brian Burkhalter <brian.burkhalter at oracle.com>, 2d-dev <2d-
> dev at openjdk.java.net>, build-dev <build-dev at openjdk.java.net>, core-libs-dev
> <core-libs-dev at openjdk.java.net>, "Lindenmaier, Goetz"
> <goetz.lindenmaier at sap.com>, Philip Race <philip.race at oracle.com>
> Date:        04/09/2018 16:41
> Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> ________________________________
> 
> 
> 
> 
> Looks good to me.
> 
> /Magnus
> 
> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard <andrew_m_leonard at uk.ibm.com
> <mailto:andrew_m_leonard at uk.ibm.com> >:
> 
> Hi Brian/Goetz,
> Yes, that seems sensible. I have created a new webrev with fdlibm compiler
> option disabled, and mediaLib code fixed:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/
> <http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/>
> I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3.
> 
> Are we good to go?
> Thanks
> Andrew
> 
> hg export:
> # HG changeset patch
> # User aleonard
> # Date 1536055438 -3600
> #      Tue Sep 04 11:03:58 2018 +0100
> # Node ID c2523f285c503e8f82f1212b38de1cb54093255e
> # Parent  3ee91722550680c18b977f0e00b1013323b5c9ef
> 8209786: JDK12 fails to build on s390x with gcc 7.3
> 
> diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmk        Tue Sep 04 14:47:55 2018 +0800
> +++ b/make/lib/CoreLibraries.gmk        Tue Sep 04 11:03:58 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, \
> diff -r 3ee917225506 -r c2523f285c50
> src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 14:47:55 2018 +0800
> +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 11:03:58 2018 +0100
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 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
> @@ -259,18 +259,18 @@
>       }
> 
> #ifdef _LITTLE_ENDIAN
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>       ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask);
> 
> #else /* _NO_LONGLONG */
> 
> #ifdef _LITTLE_ENDIAN
> -      mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
> +      mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
> #else
> -      mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
> +      mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
> 
>       ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) |
> (((mlib_u64*)da)[0] &~ emask);
> @@ -395,9 +395,9 @@
>       }
> 
> #ifdef _LITTLE_ENDIAN
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>       ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask);
> 
> @@ -413,9 +413,9 @@
>       }
> 
> #ifdef _LITTLE_ENDIAN
> -      emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
> +      emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
> #else
> -      emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
> +      emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>       ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask);
> 
> @@ -565,9 +565,9 @@
>       }
> 
> #ifdef _LITTLE_ENDIAN
> -      emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -      emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +      emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>       da[0] = (dd & emask) | (da[0] &~ emask);
>     }
> 
> 
> 
> 
> 
> 
> 
> 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:        Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
> <mailto:magnus.ihse.bursie at oracle.com> >
> Cc:        Andrew Leonard <andrew_m_leonard at uk.ibm.com
> <mailto:andrew_m_leonard at uk.ibm.com> >, "Lindenmaier, Goetz"
> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >, 2d-dev
> <2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net> >, build-dev
> <build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net> >, core-libs-
> dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>
> >, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com> >
> Date:        31/08/2018 15:44
> Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> ________________________________
> 
> 
> 
> 
> 
> On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com <mailto: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
> 
> 
> 
> 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 james.laskey at oracle.com  Thu Sep  6 13:09:03 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 6 Sep 2018 10:09:03 -0300
Subject: RFR - JDK-8200434 - String::align, String::indent (code review)
In-Reply-To: <1bd50a3e-724e-5eb3-0ddb-226066e61e70@oracle.com>
References: <866B7282-D7B1-4B63-9497-B43D7D84AC6C@oracle.com>
 <1bd50a3e-724e-5eb3-0ddb-226066e61e70@oracle.com>
Message-ID: <90F06BD4-2973-473E-84FE-A176583DBF38@oracle.com>

Revised webrev at: http://cr.openjdk.java.net/~jlaskey/8200434/webrev-01/index.html <http://cr.openjdk.java.net/~jlaskey/8200434/webrev-01/index.html>

Thank you Roger,

? Jim

> On Sep 5, 2018, at 5:07 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Jim,
> 
> Overall it looks fine. Some quibbles on the wording and the test.
> 
> 
> The spec for the align() and align(n) methods in String.java show a possibly misleading inconsistency.
> The first line says:
> 
>   Removes vertical and horizontal white space margins.
> 
> But later align() says:
> 
>   Trailing spaces are  preserved.
> 
> The former implies all 4 margins but then it seems only to apply to 3 of the 4.  (top, left, bottom).
> I'm not sure if there some wording that can clear that up in the first line.

There has been some debate on whether to drop trailing blanks or not. I?m in favour of dropping trailing blanks, but need to see some use cases.

> 
> 
> AlignIndent.java:
> 
>  - Line 28: this test should not need /othervm nor the explicit @compile
> 
>  - There should be tests of align(n) with negative values.
> 
>  - The for for for for structure doesn't follow the style guide.

Fixed, see updated webrev.

> 
> 
> Thanks, Roger
> 
> (Sorry for the duplicates, I missed core-libs the first time)
> 
> On 8/29/18 10: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
>> 
> 


From jai.forums2013 at gmail.com  Thu Sep  6 14:09:41 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 6 Sep 2018 19:39:41 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>


On 06/09/18 1:24 PM, Bernd Eckenfels wrote:
> Yes you are right @apinote is aproperiate section (was confusing it with implnote).
>
> Still think a ?literal specified list? is no longer a good (as in canonical) usecase for that method.
>
> I used it in the past often to get a List for using toString() on it, but I guess even for that case List.of can be used instead now.
>
> So @see List#of and let the reader figure out when to use them?

That sounds good to me. I've now updated it to reflect this change and
the javadoc now looks as below. I've also attached the new updated patch.

??? /**
???? * 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
???? * 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
???? * @see List#of()
???? */



-Jaikiran

-------------- next part --------------
# HG changeset patch
# User Jaikiran Pai <jaikiran.pai at gmail.com>
# Date 1535208403 -19800
#      Sat Aug 25 20:16:43 2018 +0530
# Node ID e4d5e71a20f7c80196f211f62440d3cccb69e8f3
# Parent  a716460217ed180972b568e28cf332e37e07a3ae
JDK-7033681 Improve the javadoc of Arrays#toList()

diff --git a/src/java.base/share/classes/java/util/Arrays.java b/src/java.base/share/classes/java/util/Arrays.java
--- a/src/java.base/share/classes/java/util/Arrays.java
+++ b/src/java.base/share/classes/java/util/Arrays.java
@@ -4288,21 +4288,33 @@
     // 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
-     * list initialized to contain several elements:
-     * <pre>
-     *     List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe", "Curly");
-     * </pre>
+     * 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
+     * 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
+     * @see List#of()
      */
     @SafeVarargs
     @SuppressWarnings("varargs")

From igor.ignatyev at oracle.com  Thu Sep  6 16:19:39 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 6 Sep 2018 09:19:39 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <CAF9BGBywv09PaHy6N5FWT2aHfjWPVGYX8RwMEbMD0Wt6=VyUXg@mail.gmail.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
 <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
 <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>
 <CAF9BGBywv09PaHy6N5FWT2aHfjWPVGYX8RwMEbMD0Wt6=VyUXg@mail.gmail.com>
Message-ID: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com>

JC,
thanks for your review!

Core-libs team,
as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch. 

for the record, [1] is the latest version of webrev.

[1] http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html>
> 2433 lines changed: 334 ins; 1677 del; 422 mod;

Cheers,
-- Igor


> On Sep 5, 2018, at 5:03 PM, JC Beyler <jcbeyler at google.com> wrote:
> 
> Hi Igor,
> 
> Looks good to me then. I agree most are nits, personal preferences, and just I noticed them as you were cleaning them up!
> 
> Awesome clean up :-)
> Jc
> 
> On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
> Hi JC,
> 
> 
>> On Sep 5, 2018, at 2:59 PM, JC Beyler <jcbeyler at google.com <mailto:jcbeyler at google.com>> wrote:
>> 
>> Hi Igor,
>> 
>> I like this much better! A few more comments:
>> 
>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html>
>>   -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>)
> just to follow the style used by this tests, e.g.
> 
>>   54         try {
>>   55             output.shouldContain(stdout);
>>   56             output.stdoutShouldContain(stdout);
>>   57             output.shouldContain(stderr);
>>   58             output.stderrShouldContain(stderr);
>>   59         } catch (RuntimeException e) {
>>   60             throw new Exception("shouldContain() failed", e);
>>   61         }
> 
>>   86         try {
>>   87             output.shouldNotContain(nonExistingString);
>>   88             output.stdoutShouldNotContain(nonExistingString);
>>   89             output.stderrShouldNotContain(nonExistingString);
>>   90         } catch (RuntimeException e) {
>>   91             throw new Exception("shouldNotContain() failed", e);
>>   92         }
>>   93 
> 
> 
>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>
>>    There is now only a 1-liner for this method and it is called only once, should we inline and remove the method?
> 
> we can, but I ain't sure we should. from my point of view
> 
>   80         output.shouldHaveExitValue(0);
>   81         output.shouldContain("sun.tools.jcmd.JCmd");
>   82         matchListedProcesses(output);
> is a bit easier to understand than
>   80         output.shouldHaveExitValue(0);
>   81         output.shouldContain("sun.tools.jcmd.JCmd");
>   82         output.shouldMatchByLine(JCMD_LIST_REGEX);
> 
> however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses.
> 
>> - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html>same here
> 
>> 
>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html>
>>     "There is no lines" -> "There are no lines"
> fixed. thanks for spotting.
> 
>>     - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it
> OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this.
> 
> 
>> Thanks for the incremental webrev, that made looking at the changes so much easier!
> 
> here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html>
> 
> -- Igor
>> Jc
>> 
>> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> Hi JC,
>> 
>> thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion.
>> 
>> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern.
>> 
>> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html>
>> 
>> Thanks,
>> -- Igor
>> 
>>> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com <mailto:jcbeyler at google.com>> wrote:
>>> 
>>> Hi Igor,
>>> 
>>> I reviewed the webrev but I noticed two things:
>>> 
>>> - Small nit:
>>>   - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html>
>>>      - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then?
>>> 
>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html>
>>>   - Seems we could refactor a bit this no?
>>>      - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized:
>>> 
>>> class TaskStream {
>>>    private final ByteArrayOutputStream buffer;
>>>    private Future<Void> task;
>>> 
>>>    public TaskStream(InputStream stream) {
>>>       buffer = new ByteArrayOutputStream();
>>>       task = new StreamPumper(stream, buffer).process();
>>>    }
>>> 
>>>     public String getBuffer() {
>>>       try {
>>>         task.get();
>>>         return buffer.toString();
>>>       } catch (InterruptedException e) {
>>>         Thread.currentThread().interrupt();
>>>         throw new OutputBufferException(e);
>>>       } catch (ExecutionException | CancellationException e) {
>>>         throw new OutputBufferException(e);
>>>       }
>>>     }
>>> }
>>> +  class LazyOutputBuffer implements OutputBuffer {
>>> +    private final TaskStream stderr;
>>> +    private final TaskStream stdout;
>>> +    private final Process p;
>>> +
>>> +    private LazyOutputBuffer(Process p) {
>>> +      this.p = p;
>>> +      stderr = new TaskStream(p.getInputStream());
>>> +      stdout = new TaskStream(p.getErrorStream());
>>> +    }
>>> +
>>> +    @Override
>>> +    public String getStdout() {
>>> +      return stdout.getBuffer();
>>> +    }
>>> 
>>> +    @Override
>>> +    public String getStderr() {
>>> +       return stderr.getBuffer()
>>> +    }
>>> 
>>> I think it is more clear, what do you think?
>>> 
>>> Apart from those two elements, it looks good to me :), nice refactor!
>>> Jc
>>> 
>>> 
>>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>>> > 2375 lines changed: 322 ins; 1662 del; 391 mod
>>> 
>>> Hi all,
>>> 
>>> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process?
>>> 
>>> there were a few differences b/w implementations which are addressed by the patch:
>>>  - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method
>>>  - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>>>  - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them.
>>>  - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest.
>>> 
>>> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible.  
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>>> testing: tier1-tier3 + :jdk_svc
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 <https://bugs.openjdk.java.net/browse/JDK-8210112>
>>> 
>>> Thanks,
>>> -- Igor 
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Thanks,
>>> Jc
>> 
>> 
>> 
>> -- 
>> 
>> Thanks,
>> Jc
> 
> 
> 
> -- 
> 
> Thanks,
> Jc


From erik.joelsson at oracle.com  Thu Sep  6 16:55:29 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 6 Sep 2018 09:55:29 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
Message-ID: <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>


On 2018-09-06 03:12, Severin Gehwolf wrote:
> Hi David,
>
> On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> Might as well raise this here too as it's really a build philosophy
>> issue. Shouldn't flags like -ffp-contract=off (and the existing AIX
>> -qfloat=nomaf) be toolchain specific rather than platform specific?
> Looks like Clang has -ffp-contract:
> https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract
>
> Is there any other (supported) toolchain other than gcc and clang on
> linux? As for AIX I suppose there is only on supported toolchain?
We don't have a big variety of toolchain/platform combinations that we 
actively support no, but we still try to be conscious of when a flag is 
toolchain specific and when it's platform specific. There is certainly 
interest in using other compilers on Linux, and GCC could potentially be 
used on other platforms as well. Until we actually try it, it can be 
hard to know for sure if a flag actually applies in other cases for the 
toolchain and/or platform, but we can at least try our best guess.

/Erik
> Thanks,
> Severin
>
>> Thanks,
>> David
>>
>> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Cross-posting this review-thread on core-libs-dev and build-dev as
>>> this
>>> is a build change, but affects fdlibm which is core-libs.
>>>
>>> With JDK-8170153 optimization for fdlibm code has been turned on
>>> for
>>> ppc64 s390 and aarch64. This patch intends to turn it on on all
>>> arches
>>> on Linux. I've not observed any precision issues. Is there a good
>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
>>> webrev:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>>>
>>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>>>            - Currently running through submit repo.
>>>
>>> A simple micro benchmark from JDK-8170153[1] shows these numbers
>>> for
>>> StrictMath:
>>>
>>> Function      | before     | after
>>> ----------------------------------------------
>>> sin           | 0m33.382s  | 0m18.731s
>>> cos           | 0m31.562s  | 0m18.796s
>>> tan           | 0m33.657s  | 0m21.093s
>>> atan          | 0m5.714s   | 0m4.902s
>>> log           | 0m6.212s   | 0m4.439s
>>> log10         | 0m7.946s   | 0m5.543s
>>> sqrt          | 0m0.481s   | 0m0.449s
>>> cbrt          | 0m5.295s   | 0m5.214s
>>> tanh          | 0m1.404s   | 0m1.307s
>>> log1p         | 0m6.457s   | 0m5.131s
>>> IEEEremainder | 0m10.629s  | 0m6.048s
>>> atan2         | 0m8.037s   | 0m5.668s
>>> hypot         | 0m2.171s   | 0m2.147s
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>>


From sgehwolf at redhat.com  Thu Sep  6 17:29:10 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 06 Sep 2018 19:29:10 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
Message-ID: <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>

On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
> On 2018-09-06 03:12, Severin Gehwolf wrote:
> > Hi David,
> > 
> > On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > Might as well raise this here too as it's really a build philosophy
> > > issue. Shouldn't flags like -ffp-contract=off (and the existing AIX
> > > -qfloat=nomaf) be toolchain specific rather than platform specific?
> > 
> > Looks like Clang has -ffp-contract:
> > https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract
> > 
> > Is there any other (supported) toolchain other than gcc and clang on
> > linux? As for AIX I suppose there is only on supported toolchain?
> 
> We don't have a big variety of toolchain/platform combinations that we 
> actively support no, but we still try to be conscious of when a flag is 
> toolchain specific and when it's platform specific. There is certainly 
> interest in using other compilers on Linux, and GCC could potentially be 
> used on other platforms as well. Until we actually try it, it can be 
> hard to know for sure if a flag actually applies in other cases for the 
> toolchain and/or platform, but we can at least try our best guess.

Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
contract too. Question is beginning from which version. That's why I'd
expect for those flags to work on linux. Is there anything else I need
to check?

Would it be preferred if I moved this into a block like this?

ifeq ($(TOOLCHAIN_TYPE), gcc)
  [...]
endif

Thanks,
Severin

> /Erik
> > Thanks,
> > Severin
> > 
> > > Thanks,
> > > David
> > > 
> > > On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Cross-posting this review-thread on core-libs-dev and build-dev as
> > > > this
> > > > is a build change, but affects fdlibm which is core-libs.
> > > > 
> > > > With JDK-8170153 optimization for fdlibm code has been turned on
> > > > for
> > > > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > > > arches
> > > > on Linux. I've not observed any precision issues. Is there a good
> > > > reason to not use -O3 -ffp-contract=off everywhere?
> > > > 
> > > > Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> > > > webrev:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > > > 
> > > > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> > > >            - Currently running through submit repo.
> > > > 
> > > > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > > > for
> > > > StrictMath:
> > > > 
> > > > Function      | before     | after
> > > > ----------------------------------------------
> > > > sin           | 0m33.382s  | 0m18.731s
> > > > cos           | 0m31.562s  | 0m18.796s
> > > > tan           | 0m33.657s  | 0m21.093s
> > > > atan          | 0m5.714s   | 0m4.902s
> > > > log           | 0m6.212s   | 0m4.439s
> > > > log10         | 0m7.946s   | 0m5.543s
> > > > sqrt          | 0m0.481s   | 0m0.449s
> > > > cbrt          | 0m5.295s   | 0m5.214s
> > > > tanh          | 0m1.404s   | 0m1.307s
> > > > log1p         | 0m6.457s   | 0m5.131s
> > > > IEEEremainder | 0m10.629s  | 0m6.048s
> > > > atan2         | 0m8.037s   | 0m5.668s
> > > > hypot         | 0m2.171s   | 0m2.147s
> > > > 
> > > > Thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> 
> 


From roger.riggs at oracle.com  Thu Sep  6 17:42:14 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 6 Sep 2018 13:42:14 -0400
Subject: [12] RFR: 8210142: java.util.Calendar.clone() doesn't respect
 sharedZone flag
In-Reply-To: <4807130c-9273-43d5-165a-9ad9905592a7@oracle.com>
References: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>
 <caaaa7cd-483d-336c-9a46-1addd0c8f987@Oracle.com>
 <44ebd8e5-9418-8a79-6609-fae9f02dc3c5@oracle.com>
 <ebeed781-aa72-17bd-ada4-b03be71b7190@oracle.com>
 <18c083fe-e22e-be08-97c6-d8a7dc02e68b@oracle.com>
 <35c46503-afea-50af-2f93-4ab3e447ba2b@oracle.com>
 <4807130c-9273-43d5-165a-9ad9905592a7@oracle.com>
Message-ID: <aa59b7af-a269-335e-a8a5-7cb08a525eba@oracle.com>

Looks good, thanks for the update.

Roger


On 9/5/18 5:10 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> I updated the fix to share the zone only if the sharedZone is true. 
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8210142/webrev.01/
>
> Naoto
>
> On 9/5/18 7:07 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> That sounds like a test issue.? I would not expect a cloned Calendar 
>> or TimeZone to have a different hashCode.
>> None of the fields involved in the hashCode/equals should be 
>> different. (Or I'm missing something about them).
>>
>> Thanks, Roger
>>
>>
>> On 9/4/18 5:19 PM, Naoto Sato wrote:
>>> Hi Roger,
>>>
>>> I tentatively tried to return a shared zone within a cloned 
>>> Calendar. One test failed: 
>>> java/util/Calendar/CalendarRegression.Test4136399, where it makes 
>>> sure that the cloned Calendar object hash code should be different 
>>> for the better distribution. Although the comment does not reflect 
>>> the current implementation (getTimeZone() returning cloned zone), 
>>> the intention here seems to have the better hash distribution for 
>>> cloned objects.
>>>
>>> Naoto
>>>
>>> On 9/4/18 1:41 PM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> That access via reflection is going to go away sometime; so I'm not 
>>>> too concerned about
>>>> maintaining compatibility of the internal implementation.
>>>> I think I'd rather see the memory savings, however small.
>>>> Let see if anyone else has a recommendation.
>>>>
>>>> Roger
>>>>
>>>>
>>>> On 9/4/18 4:12 PM, Naoto Sato wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Yes, I considered that too, but did not change the behavior and 
>>>>> just to maintain the field consistent. I agree that it would not 
>>>>> be observable via the public Calendar API, but some apps (like how 
>>>>> the submitter found it) may be doing something using reflection.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 9/4/18 12:31 PM, Roger Riggs wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> The spec for clone doesn't say whether the clone should share or 
>>>>>> not share the TimeZone.
>>>>>> Did you consider that if sharedZone was true , *not* to clone the 
>>>>>> TimeZone?
>>>>>> It would still get cloned when requested from getTimeZone().
>>>>>>
>>>>>> This does seem somewhat safer not to change the cloning behavior 
>>>>>> but I don't think the behavior would be observable.
>>>>>>
>>>>>> The current code and test is fine, except for reducing the 
>>>>>> potential for sharing the TimeZone.
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>> On 9/4/2018 2:14 PM, Naoto Sato wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the fix to the following issue:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210142
>>>>>>>
>>>>>>> The proposed fix is located at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8210142/webrev.00/
>>>>>>>
>>>>>>> The fix is a simple one line change, which is to make the 
>>>>>>> sharedZone field consistent with the cloned TimeZone instance in 
>>>>>>> Calendar.clone().
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>
>>


From erik.joelsson at oracle.com  Thu Sep  6 17:55:53 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 6 Sep 2018 10:55:53 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
Message-ID: <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>


On 2018-09-06 10:29, Severin Gehwolf wrote:
> On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
> Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
> contract too. Question is beginning from which version. That's why I'd
> expect for those flags to work on linux. Is there anything else I need
> to check?
>
> Would it be preferred if I moved this into a block like this?
>
> ifeq ($(TOOLCHAIN_TYPE), gcc)
>    [...]
> endif
Yes, making it conditional on toolchain type is what David was after. 
You can also consider adding a capability check if you know that 
versions of the compiler that should still work don't have the feature.

/Erik
> Thanks,
> Severin
>
>> /Erik
>>> Thanks,
>>> Severin
>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
>>>>> Hi,
>>>>>
>>>>> Cross-posting this review-thread on core-libs-dev and build-dev as
>>>>> this
>>>>> is a build change, but affects fdlibm which is core-libs.
>>>>>
>>>>> With JDK-8170153 optimization for fdlibm code has been turned on
>>>>> for
>>>>> ppc64 s390 and aarch64. This patch intends to turn it on on all
>>>>> arches
>>>>> on Linux. I've not observed any precision issues. Is there a good
>>>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>>>
>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>>>>>
>>>>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>>>>>             - Currently running through submit repo.
>>>>>
>>>>> A simple micro benchmark from JDK-8170153[1] shows these numbers
>>>>> for
>>>>> StrictMath:
>>>>>
>>>>> Function      | before     | after
>>>>> ----------------------------------------------
>>>>> sin           | 0m33.382s  | 0m18.731s
>>>>> cos           | 0m31.562s  | 0m18.796s
>>>>> tan           | 0m33.657s  | 0m21.093s
>>>>> atan          | 0m5.714s   | 0m4.902s
>>>>> log           | 0m6.212s   | 0m4.439s
>>>>> log10         | 0m7.946s   | 0m5.543s
>>>>> sqrt          | 0m0.481s   | 0m0.449s
>>>>> cbrt          | 0m5.295s   | 0m5.214s
>>>>> tanh          | 0m1.404s   | 0m1.307s
>>>>> log1p         | 0m6.457s   | 0m5.131s
>>>>> IEEEremainder | 0m10.629s  | 0m6.048s
>>>>> atan2         | 0m8.037s   | 0m5.668s
>>>>> hypot         | 0m2.171s   | 0m2.147s
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>>>
>>


From xueming.shen at oracle.com  Fri Sep  7 07:41:13 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 07 Sep 2018 00:41:13 -0700
Subject: RFR JDK-8210345: The Japanese message of FileNotFoundException garbled
Message-ID: <5B922B99.1040605@oracle.com>

Hi

Please help review the changeset for JDK-8210345.

issue: https://bugs.openjdk.java.net/browse/JDK-8210345
webrev: http://cr.openjdk.java.net/~sherman/8210345/webrev

This is a "regression" from the change we made for JDK-8200243 [1], in 
which the
getLastErrorString() for windows platform was updated back to use the 
platform
encoding, instead of the incorrect utf8. However the corresponding 
change (to use
JNU_NewStringPlatform to encode the err msg) in io_util.c was missed out.

We currently don't have a auto-regression test with corresponding 
machine_locale
setup/configuration for this one, Pallavi.Sonal kindly helped to 
verified it manually
on his local setup (see attached). It would be desired to have a 
specific testing
configuration to catch such error going forward, but it would be better done
separately.

Thanks,
Sherman

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

-----------------

I could run the test case with you mach5 download and it is giving expected output :
C:\Test>C:\Test\jdk-12\bin\java -showversion JI9057040
java version "12-internal" 2019-03-19
Java(TM) SE Runtime Environment 19.3 (build 12-internal+0-2018-09-05-0009528.xueming.shen.jdk12)
Java HotSpot(TM) 64-Bit Server VM 19.3 (build 12-internal+0-2018-09-05-0009528.xueming.shen.jdk12, mixed mode)
ja_JP
java.io.FileNotFoundException: testabc.txt (??????????????????)
         at java.base/java.io.FileInputStream.open0(Native Method)
         at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
         at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
         at java.base/java.io.FileInputStream.<init>(FileInputStream.java:112)
         at java.base/java.io.FileReader.<init>(FileReader.java:60)
         at JI9057040.main(JI9057040.java:10)
testabc.txt (??????????????????)
testabc.txt (??????????????????)




From sgehwolf at redhat.com  Fri Sep  7 08:01:50 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 07 Sep 2018 10:01:50 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
Message-ID: <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>

Hi,

On Thu, 2018-09-06 at 10:55 -0700, Erik Joelsson wrote:
> On 2018-09-06 10:29, Severin Gehwolf wrote:
> > On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
> > Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
> > contract too. Question is beginning from which version. That's why I'd
> > expect for those flags to work on linux. Is there anything else I need
> > to check?
> > 
> > Would it be preferred if I moved this into a block like this?
> > 
> > ifeq ($(TOOLCHAIN_TYPE), gcc)
> >    [...]
> > endif
> 
> Yes, making it conditional on toolchain type is what David was after.

Right. David, given that -ffp-contract is available for clang too, do
you still want me to add this into a toolchain specific block?

Also note that solaris doesn't seem to be handling this code any
special, so there would be a difference between gcc + solaris and
solstudio + solaris. Rather hypothetical case, I suppose, but still ;-) 
One of the arguments were that gcc is being used on other platforms
than linux.

> You can also consider adding a capability check if you know that 
> versions of the compiler that should still work don't have the feature.

One clarification: Does a capability check mean doing this at the
configure step or is there a way one has access to toolchain versions
in make files?

Thanks,
Severin

> /Erik
> > Thanks,
> > Severin
> > 
> > > /Erik
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > Thanks,
> > > > > David
> > > > > 
> > > > > On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Cross-posting this review-thread on core-libs-dev and build-dev as
> > > > > > this
> > > > > > is a build change, but affects fdlibm which is core-libs.
> > > > > > 
> > > > > > With JDK-8170153 optimization for fdlibm code has been turned on
> > > > > > for
> > > > > > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > > > > > arches
> > > > > > on Linux. I've not observed any precision issues. Is there a good
> > > > > > reason to not use -O3 -ffp-contract=off everywhere?
> > > > > > 
> > > > > > Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
> > > > > > webrev:
> > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > > > > > 
> > > > > > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> > > > > >             - Currently running through submit repo.
> > > > > > 
> > > > > > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > > > > > for
> > > > > > StrictMath:
> > > > > > 
> > > > > > Function      | before     | after
> > > > > > ----------------------------------------------
> > > > > > sin           | 0m33.382s  | 0m18.731s
> > > > > > cos           | 0m31.562s  | 0m18.796s
> > > > > > tan           | 0m33.657s  | 0m21.093s
> > > > > > atan          | 0m5.714s   | 0m4.902s
> > > > > > log           | 0m6.212s   | 0m4.439s
> > > > > > log10         | 0m7.946s   | 0m5.543s
> > > > > > sqrt          | 0m0.481s   | 0m0.449s
> > > > > > cbrt          | 0m5.295s   | 0m5.214s
> > > > > > tanh          | 0m1.404s   | 0m1.307s
> > > > > > log1p         | 0m6.457s   | 0m5.131s
> > > > > > IEEEremainder | 0m10.629s  | 0m6.048s
> > > > > > atan2         | 0m8.037s   | 0m5.668s
> > > > > > hypot         | 0m2.171s   | 0m2.147s
> > > > > > 
> > > > > > Thoughts?
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > > 
> 
> 


From serguei.spitsyn at oracle.com  Fri Sep  7 08:05:12 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 7 Sep 2018 01:05:12 -0700
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
 <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
 <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>
 <CAF9BGBywv09PaHy6N5FWT2aHfjWPVGYX8RwMEbMD0Wt6=VyUXg@mail.gmail.com>
 <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com>
Message-ID: <d2607271-6809-e368-6626-95ed570bd5d5@oracle.com>

Hi Igor,

I do not see any issues with this refactoring.

Thanks,
Serguei


On 9/6/18 09:19, Igor Ignatyev wrote:
> JC,
> thanks for your review!
>
> Core-libs team,
> as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch.
>
> for the record, [1] is the latest version of webrev.
>
> [1] http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html>
>> 2433 lines changed: 334 ins; 1677 del; 422 mod;
> Cheers,
> -- Igor
>
>
>> On Sep 5, 2018, at 5:03 PM, JC Beyler <jcbeyler at google.com> wrote:
>>
>> Hi Igor,
>>
>> Looks good to me then. I agree most are nits, personal preferences, and just I noticed them as you were cleaning them up!
>>
>> Awesome clean up :-)
>> Jc
>>
>> On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> Hi JC,
>>
>>
>>> On Sep 5, 2018, at 2:59 PM, JC Beyler <jcbeyler at google.com <mailto:jcbeyler at google.com>> wrote:
>>>
>>> Hi Igor,
>>>
>>> I like this much better! A few more comments:
>>>
>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html>
>>>    -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>)
>> just to follow the style used by this tests, e.g.
>>
>>>    54         try {
>>>    55             output.shouldContain(stdout);
>>>    56             output.stdoutShouldContain(stdout);
>>>    57             output.shouldContain(stderr);
>>>    58             output.stderrShouldContain(stderr);
>>>    59         } catch (RuntimeException e) {
>>>    60             throw new Exception("shouldContain() failed", e);
>>>    61         }
>>>    86         try {
>>>    87             output.shouldNotContain(nonExistingString);
>>>    88             output.stdoutShouldNotContain(nonExistingString);
>>>    89             output.stderrShouldNotContain(nonExistingString);
>>>    90         } catch (RuntimeException e) {
>>>    91             throw new Exception("shouldNotContain() failed", e);
>>>    92         }
>>>    93
>>
>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html>
>>>     There is now only a 1-liner for this method and it is called only once, should we inline and remove the method?
>> we can, but I ain't sure we should. from my point of view
>>
>>    80         output.shouldHaveExitValue(0);
>>    81         output.shouldContain("sun.tools.jcmd.JCmd");
>>    82         matchListedProcesses(output);
>> is a bit easier to understand than
>>    80         output.shouldHaveExitValue(0);
>>    81         output.shouldContain("sun.tools.jcmd.JCmd");
>>    82         output.shouldMatchByLine(JCMD_LIST_REGEX);
>>
>> however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses.
>>
>>> - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html>same here
>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html>
>>>      "There is no lines" -> "There are no lines"
>> fixed. thanks for spotting.
>>
>>>      - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it
>> OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this.
>>
>>
>>> Thanks for the incremental webrev, that made looking at the changes so much easier!
>> here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html>
>>
>> -- Igor
>>> Jc
>>>
>>> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>> Hi JC,
>>>
>>> thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion.
>>>
>>> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern.
>>>
>>> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html>
>>>
>>> Thanks,
>>> -- Igor
>>>
>>>> On Sep 4, 2018, at 8:01 PM, JC Beyler <jcbeyler at google.com <mailto:jcbeyler at google.com>> wrote:
>>>>
>>>> Hi Igor,
>>>>
>>>> I reviewed the webrev but I noticed two things:
>>>>
>>>> - Small nit:
>>>>    - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html>
>>>>       - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then?
>>>>
>>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html>
>>>>    - Seems we could refactor a bit this no?
>>>>       - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized:
>>>>
>>>> class TaskStream {
>>>>     private final ByteArrayOutputStream buffer;
>>>>     private Future<Void> task;
>>>>
>>>>     public TaskStream(InputStream stream) {
>>>>        buffer = new ByteArrayOutputStream();
>>>>        task = new StreamPumper(stream, buffer).process();
>>>>     }
>>>>
>>>>      public String getBuffer() {
>>>>        try {
>>>>          task.get();
>>>>          return buffer.toString();
>>>>        } catch (InterruptedException e) {
>>>>          Thread.currentThread().interrupt();
>>>>          throw new OutputBufferException(e);
>>>>        } catch (ExecutionException | CancellationException e) {
>>>>          throw new OutputBufferException(e);
>>>>        }
>>>>      }
>>>> }
>>>> +  class LazyOutputBuffer implements OutputBuffer {
>>>> +    private final TaskStream stderr;
>>>> +    private final TaskStream stdout;
>>>> +    private final Process p;
>>>> +
>>>> +    private LazyOutputBuffer(Process p) {
>>>> +      this.p = p;
>>>> +      stderr = new TaskStream(p.getInputStream());
>>>> +      stdout = new TaskStream(p.getErrorStream());
>>>> +    }
>>>> +
>>>> +    @Override
>>>> +    public String getStdout() {
>>>> +      return stdout.getBuffer();
>>>> +    }
>>>>
>>>> +    @Override
>>>> +    public String getStderr() {
>>>> +       return stderr.getBuffer()
>>>> +    }
>>>>
>>>> I think it is more clear, what do you think?
>>>>
>>>> Apart from those two elements, it looks good to me :), nice refactor!
>>>> Jc
>>>>
>>>>
>>>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>>>>> 2375 lines changed: 322 ins; 1662 del; 391 mod
>>>> Hi all,
>>>>
>>>> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process?
>>>>
>>>> there were a few differences b/w implementations which are addressed by the patch:
>>>>   - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method
>>>>   - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family
>>>>   - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them.
>>>>   - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest.
>>>>
>>>> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html>
>>>> testing: tier1-tier3 + :jdk_svc
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 <https://bugs.openjdk.java.net/browse/JDK-8210112>
>>>>
>>>> Thanks,
>>>> -- Igor
>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> Thanks,
>>>> Jc
>>>
>>>
>>> -- 
>>>
>>> Thanks,
>>> Jc
>>
>>
>> -- 
>>
>> Thanks,
>> Jc


From Alan.Bateman at oracle.com  Fri Sep  7 08:09:42 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 7 Sep 2018 09:09:42 +0100
Subject: RFR JDK-8210345: The Japanese message of FileNotFoundException
 garbled
In-Reply-To: <5B922B99.1040605@oracle.com>
References: <5B922B99.1040605@oracle.com>
Message-ID: <73fccb2c-a199-3eb2-1053-f188c8b1559d@oracle.com>



On 07/09/2018 08:41, Xueming Shen wrote:
> :
>
> We currently don't have a auto-regression test with corresponding 
> machine_locale
> setup/configuration for this one, Pallavi.Sonal kindly helped to 
> verified it manually
> on his local setup (see attached). It would be desired to have a 
> specific testing
> configuration to catch such error going forward, but it would be 
> better done
> separately.
This change looks fine, and easy to miss because it was specific to the 
FNF exception.

Yes, we do need to do something to help catch issues like this easier, 
esp. Japanese and Chinese versions of Windows where we've had several 
issues over the years. I think we'll need a test that uses a range of 
exceptions from different areas to make sure that we've got all these 
code paths.

-Alan

From david.holmes at oracle.com  Fri Sep  7 08:56:23 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 7 Sep 2018 18:56:23 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
Message-ID: <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>

Hi Severin,

On 7/09/2018 6:01 PM, Severin Gehwolf wrote:
> Hi,
> 
> On Thu, 2018-09-06 at 10:55 -0700, Erik Joelsson wrote:
>> On 2018-09-06 10:29, Severin Gehwolf wrote:
>>> On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
>>> Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
>>> contract too. Question is beginning from which version. That's why I'd
>>> expect for those flags to work on linux. Is there anything else I need
>>> to check?
>>>
>>> Would it be preferred if I moved this into a block like this?
>>>
>>> ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>     [...]
>>> endif
>>
>> Yes, making it conditional on toolchain type is what David was after.
> 
> Right. David, given that -ffp-contract is available for clang too, do
> you still want me to add this into a toolchain specific block?

Personally I'd prefer it but I will defer to Erik and Magnus on this.

Thanks,
David

> Also note that solaris doesn't seem to be handling this code any
> special, so there would be a difference between gcc + solaris and
> solstudio + solaris. Rather hypothetical case, I suppose, but still ;-)
> One of the arguments were that gcc is being used on other platforms
> than linux.
> 
>> You can also consider adding a capability check if you know that
>> versions of the compiler that should still work don't have the feature.
> 
> One clarification: Does a capability check mean doing this at the
> configure step or is there a way one has access to toolchain versions
> in make files?
> 
> Thanks,
> Severin
> 
>> /Erik
>>> Thanks,
>>> Severin
>>>
>>>> /Erik
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Cross-posting this review-thread on core-libs-dev and build-dev as
>>>>>>> this
>>>>>>> is a build change, but affects fdlibm which is core-libs.
>>>>>>>
>>>>>>> With JDK-8170153 optimization for fdlibm code has been turned on
>>>>>>> for
>>>>>>> ppc64 s390 and aarch64. This patch intends to turn it on on all
>>>>>>> arches
>>>>>>> on Linux. I've not observed any precision issues. Is there a good
>>>>>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>>>>>
>>>>>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>>>>>>>
>>>>>>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>>>>>>>              - Currently running through submit repo.
>>>>>>>
>>>>>>> A simple micro benchmark from JDK-8170153[1] shows these numbers
>>>>>>> for
>>>>>>> StrictMath:
>>>>>>>
>>>>>>> Function      | before     | after
>>>>>>> ----------------------------------------------
>>>>>>> sin           | 0m33.382s  | 0m18.731s
>>>>>>> cos           | 0m31.562s  | 0m18.796s
>>>>>>> tan           | 0m33.657s  | 0m21.093s
>>>>>>> atan          | 0m5.714s   | 0m4.902s
>>>>>>> log           | 0m6.212s   | 0m4.439s
>>>>>>> log10         | 0m7.946s   | 0m5.543s
>>>>>>> sqrt          | 0m0.481s   | 0m0.449s
>>>>>>> cbrt          | 0m5.295s   | 0m5.214s
>>>>>>> tanh          | 0m1.404s   | 0m1.307s
>>>>>>> log1p         | 0m6.457s   | 0m5.131s
>>>>>>> IEEEremainder | 0m10.629s  | 0m6.048s
>>>>>>> atan2         | 0m8.037s   | 0m5.668s
>>>>>>> hypot         | 0m2.171s   | 0m2.147s
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Severin
>>>>>>>
>>>>>>>
>>
>>
> 

From vyom.tewari at oracle.com  Fri Sep  7 09:11:19 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Fri, 7 Sep 2018 14:41:19 +0530
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
Message-ID: <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>

Hi Daniel,

Thanks for detailed review and comment. Please find my answers inline.

Thanks,

Vyom


On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
> Hi Vyom,
>
> IIUC, the issue only happens when connections (clients?) to the
> server are pooled. I assume the server may decide to
> close what it thinks is an idle connection at any time.
>
correct
> So what we see here is actually a race between an open
> connection being retrieved from the pool, and the server
> deciding to close that connection.
> The connection/client is retrieved from the pool, then
> unfortunately closed by the server after having been selected
> for the next operation.
>
I checked? the code and i did not found any problem. Both "get" and 
"removePooledConnection" are "synchronized" so there should not be any 
problem(concurrency issue) here.

As you said server is closing the same connection which is retrieved 
from pool which? is correct but this should not throw unintentional NPE.

In LdapClient, we set the "Ldapclient.conn" to explicitly null 
asynchronously after we remove the connection from pool and which is 
creating the NPE.

LdapClient does not set `Ldapclient.conn` to null if connection is not 
pooled.

> The question for me would be "what is the expected behavior
> if the server decides to close an idle connection?"
> I would expect that new InitialDirContext() should have some
> way of dealing with that with retrying?
> If so will leaving the 'conn' field assigned ensure that
> the retry happens, or will new InitialDirContext() fail
> with some other exception because the connection has
> been closed? Or does the code simply assume that asynchronous
> closing of the connection by the server can only happen while
> it's sitting idle in the pool?
>
 ?I don't know if retrying is feasible in 'IntialDirContext' but if we 
leave 'LdapClient.conn' assigned then we will get 
"javax.naming.CommunicationException" which tells that, underline 
connection is closed. I am not 100% sure if this is right approach but 
if we set 'LdapClient.conn' to null asynchronously then we will hit NPE.

> I wonder if some other mechanism could be used to reduce
> and hopefully eliminate the time window in which the race
> could appear. For instance taking the connection out of
> the pool before closing it, instead of closing it before
> taking it out of the pool, etc...
>
Changing order will not help, i think closing the? same connection is 
not a problem? but setting `LdapClient.conn'? to null asynchronously is 
causing NPE.

Please do let me know if i am missing something.

> best regards,
>
> -- daniel
>
> On 04/09/2018 15:04, vyom tewari wrote:
>>
>>
>> On Friday 24 August 2018 08:52 PM, Chris Hegarty wrote:
>>> 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.
>>>
>> Hi Chris, let me try to explain issue little bit.
>>
>> The issue is a if ldap connection has already been established and 
>> then the LDAP directory server sends an (unsolicited) "Notice of 
>> Disconnection", the client's processing of this LDAP message can race 
>> with an application thread calling new InitialDirContext() to 
>> authenticate user credentials (i.e.bind) and throw NPE.
>>
>> I did some analysis and found out that when server send an 
>> (unsolicited) "Notice of Disconnection", LdapClient.forceClose() will 
>> be called in LdapClient.processUnsolicited() which is called 
>> asynchronously by the reader thread in Connection, this means 
>> 'LdapClient.conn' may set to null anytime after it received? "Notice 
>> of Disconnection".
>>
>>> 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 ).
>>>
>> I agree, not setting? 'conn' to null will definitely have some 
>> impact. I check the LdapClient and it looks to me it is intentional(i 
>> may be wrong) that 'conn' is operated on both from within synchronize 
>> blocks and from unsynchronize block.
>>
>> LdapClient, java doc says that connection(conn) take care of it's own 
>> sync.
>>
>> ##################################
>> ??? access from outside LdapClient must sync;
>> ??*?? conn - no sync; Connection takes care of its own sync
>> ??*?? unsolicited - sync Vector; multiple operations sync'ed
>>
>> ##################################
>>
>> Please have a look and do let me know your thought on the above.
>>
>> Thanks,
>> Vyom
>>> -Chris.
>>
>


From Alan.Bateman at oracle.com  Fri Sep  7 13:05:57 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 7 Sep 2018 14:05:57 +0100
Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools
In-Reply-To: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com>
References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com>
 <CAF9BGByJDywFtC8koZK+RxcNxUsy7ZENgAQJ2T2WbbxPgoALew@mail.gmail.com>
 <CA472E3A-8BCF-4E8C-AF5B-CB8621229AB1@oracle.com>
 <CAF9BGBwng5Yudod_LGtmJQWEj-_SjABscjA7ZabgfJSpzhwLRw@mail.gmail.com>
 <CAF3BBAC-D926-4A5C-8FBD-181B7D2B0360@oracle.com>
 <CAF9BGBywv09PaHy6N5FWT2aHfjWPVGYX8RwMEbMD0Wt6=VyUXg@mail.gmail.com>
 <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com>
Message-ID: <fe6efbe6-e270-9959-b677-61e10bada165@oracle.com>

On 06/09/2018 17:19, Igor Ignatyev wrote:
> JC,
> thanks for your review!
>
> Core-libs team,
> as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch.
>
>
I skimmed through a sample of the test changes and was pleased to see 
that it's just the test tags that have changed. Also pleased to see that 
the shouldXXX methods now consistently return the OutputAnalyzer (this 
seems to be one area where the version in testlibrary was different). I 
don't have time to do a detail review of the updated 
ProcessTools/OutputAnalyzer but I think you have enough reviewers already.

-Alan

From erik.joelsson at oracle.com  Fri Sep  7 16:12:42 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 7 Sep 2018 09:12:42 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
Message-ID: <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>

On 2018-09-07 01:56, David Holmes wrote:
> Hi Severin,
>
> On 7/09/2018 6:01 PM, Severin Gehwolf wrote:
>> Hi,
>>
>> On Thu, 2018-09-06 at 10:55 -0700, Erik Joelsson wrote:
>>> On 2018-09-06 10:29, Severin Gehwolf wrote:
>>>> On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
>>>> Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
>>>> contract too. Question is beginning from which version. That's why I'd
>>>> expect for those flags to work on linux. Is there anything else I need
>>>> to check?
>>>>
>>>> Would it be preferred if I moved this into a block like this?
>>>>
>>>> ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> ??? [...]
>>>> endif
>>>
>>> Yes, making it conditional on toolchain type is what David was after.
>>
>> Right. David, given that -ffp-contract is available for clang too, do
>> you still want me to add this into a toolchain specific block?
>
> Personally I'd prefer it but I will defer to Erik and Magnus on this.
>
To me it sounds like we want this flag if the toolchain is either gcc or 
clang, so please make it conditional on that.

/Erik
> Thanks,
> David
>
>> Also note that solaris doesn't seem to be handling this code any
>> special, so there would be a difference between gcc + solaris and
>> solstudio + solaris. Rather hypothetical case, I suppose, but still ;-)
>> One of the arguments were that gcc is being used on other platforms
>> than linux.
>>
>>> You can also consider adding a capability check if you know that
>>> versions of the compiler that should still work don't have the feature.
>>
>> One clarification: Does a capability check mean doing this at the
>> configure step or is there a way one has access to toolchain versions
>> in make files?
>>
>> Thanks,
>> Severin
>>
>>> /Erik
>>>> Thanks,
>>>> Severin
>>>>
>>>>> /Erik
>>>>>> Thanks,
>>>>>> Severin
>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Cross-posting this review-thread on core-libs-dev and build-dev as
>>>>>>>> this
>>>>>>>> is a build change, but affects fdlibm which is core-libs.
>>>>>>>>
>>>>>>>> With JDK-8170153 optimization for fdlibm code has been turned on
>>>>>>>> for
>>>>>>>> ppc64 s390 and aarch64. This patch intends to turn it on on all
>>>>>>>> arches
>>>>>>>> on Linux. I've not observed any precision issues. Is there a good
>>>>>>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210416
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/ 
>>>>>>>>
>>>>>>>>
>>>>>>>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>>>>>>>> ???????????? - Currently running through submit repo.
>>>>>>>>
>>>>>>>> A simple micro benchmark from JDK-8170153[1] shows these numbers
>>>>>>>> for
>>>>>>>> StrictMath:
>>>>>>>>
>>>>>>>> Function????? | before???? | after
>>>>>>>> ----------------------------------------------
>>>>>>>> sin?????????? | 0m33.382s? | 0m18.731s
>>>>>>>> cos?????????? | 0m31.562s? | 0m18.796s
>>>>>>>> tan?????????? | 0m33.657s? | 0m21.093s
>>>>>>>> atan????????? | 0m5.714s?? | 0m4.902s
>>>>>>>> log?????????? | 0m6.212s?? | 0m4.439s
>>>>>>>> log10???????? | 0m7.946s?? | 0m5.543s
>>>>>>>> sqrt????????? | 0m0.481s?? | 0m0.449s
>>>>>>>> cbrt????????? | 0m5.295s?? | 0m5.214s
>>>>>>>> tanh????????? | 0m1.404s?? | 0m1.307s
>>>>>>>> log1p???????? | 0m6.457s?? | 0m5.131s
>>>>>>>> IEEEremainder | 0m10.629s? | 0m6.048s
>>>>>>>> atan2???????? | 0m8.037s?? | 0m5.668s
>>>>>>>> hypot???????? | 0m2.171s?? | 0m2.147s
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Severin
>>>>>>>>
>>>>>>>>
>>>
>>>
>>


From daniel.fuchs at oracle.com  Fri Sep  7 16:47:35 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 7 Sep 2018 17:47:35 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
Message-ID: <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>

Hi Vyom,

Please see inline... I've elided some parts...

On 07/09/2018 10:11, vyom tewari wrote:
> On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
>> So what we see here is actually a race between an open
>> connection being retrieved from the pool, and the server
>> deciding to close that connection.
>> The connection/client is retrieved from the pool, then
>> unfortunately closed by the server after having been selected
>> for the next operation.
>>
> I checked? the code and i did not found any problem. Both "get" and 
> "removePooledConnection" are "synchronized" so there should not be any 
> problem(concurrency issue) here.

I'm referring to this pattern (in forceClose):

             conn.cleanup(null, false);
             conn = null;

             if (cleanPool) {
                 pcb.removePooledConnection(this);
             }

The connection is cleaned up, then nulled, then only removed
from the pool. I'm questioning whether the first thing to do would
be to remove the connection from the pool, to reduce the time window
in which the client could be retrieved from the pool by another
thread while forceClose is in process.

I am not sure what side effect this could have - as I haven't
studied the code that retrieves the client from the pool,
but I'm wondering whether that's worth exploring.

> As you said server is closing the same connection which is retrieved 
> from pool which? is correct but this should not throw unintentional NPE.

Agreed.

> In LdapClient, we set the "Ldapclient.conn" to explicitly null 
> asynchronously after we remove the connection from pool and which is 
> creating the NPE.
> 
> LdapClient does not set `Ldapclient.conn` to null if connection is not 
> pooled.

Really? That's not what I see... Am I missing something?

 >> [...]
>> If so will leaving the 'conn' field assigned ensure that
>> the retry happens, or will new InitialDirContext() fail
>> with some other exception because the connection has
>> been closed? Or does the code simply assume that asynchronous
>> closing of the connection by the server can only happen while
>> it's sitting idle in the pool?
>>
>  ?I don't know if retrying is feasible in 'IntialDirContext' but if we 
> leave 'LdapClient.conn' assigned then we will get 
> "javax.naming.CommunicationException" which tells that, underline 
> connection is closed. I am not 100% sure if this is right approach but 
> if we set 'LdapClient.conn' to null asynchronously then we will hit NPE.

OK - that's good to know. I agree that CommunicationException is
better than NPE. If so then not nulling the connection
is at least an improvement.
But this would deserve a comment in the code, I think.
More below...

>> I wonder if some other mechanism could be used to reduce
>> and hopefully eliminate the time window in which the race
>> could appear. For instance taking the connection out of
>> the pool before closing it, instead of closing it before
>> taking it out of the pool, etc...
>>
> Changing order will not help, i think closing the? same connection is 
> not a problem? but setting `LdapClient.conn'? to null asynchronously is 
> causing NPE.

Yes - I agree that setting conn to null is problematic.
I wonder why it's set to null. Maybe in an attempt to
make it eligible for GC earlier?

If that's not the issue, then I would suggest making it
final (AFAICS it's only set to non-null once) and cleaning
up the code that tests for conn == null.

If GC is the issue, then the best you can do is probably
only set it to null when the client is not pooled.

And if we could reduce the time window in which a thread
could get a stale client from the pool that might be good
too?

Is there anyway we could somehow add a test that reproduce
the NPE?

best regards,

-- daniel

[...]

>>>> 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.
[...]

From sgehwolf at redhat.com  Fri Sep  7 16:56:42 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 07 Sep 2018 18:56:42 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
Message-ID: <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>

On Fri, 2018-09-07 at 09:12 -0700, Erik Joelsson wrote:
> On 2018-09-07 01:56, David Holmes wrote:
> > Hi Severin,
> > 
> > On 7/09/2018 6:01 PM, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > On Thu, 2018-09-06 at 10:55 -0700, Erik Joelsson wrote:
> > > > On 2018-09-06 10:29, Severin Gehwolf wrote:
> > > > > On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
> > > > > Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
> > > > > contract too. Question is beginning from which version. That's why I'd
> > > > > expect for those flags to work on linux. Is there anything else I need
> > > > > to check?
> > > > > 
> > > > > Would it be preferred if I moved this into a block like this?
> > > > > 
> > > > > ifeq ($(TOOLCHAIN_TYPE), gcc)
> > > > >     [...]
> > > > > endif
> > > > 
> > > > Yes, making it conditional on toolchain type is what David was after.
> > > 
> > > Right. David, given that -ffp-contract is available for clang too, do
> > > you still want me to add this into a toolchain specific block?
> > 
> > Personally I'd prefer it but I will defer to Erik and Magnus on this.
> > 
> 
> To me it sounds like we want this flag if the toolchain is either gcc or 
> clang, so please make it conditional on that.

Updated webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.02/

It now only sets FDLIBM_CFLAGS if gcc supports it and builds fdlibm
without opt if not. Otherwise it uses -O3 and -ffp-contract=off. If the
toolchain is clang and on linux it always uses -O3 and -ffp-
contract=off. The reason, I've done this in configure is a potential
follow-up fix for hotspot via JDK-8210425 where the CFLAGS could get
re-used. Thoughts?

Thanks,
Severin

> /Erik
> > Thanks,
> > David
> > 
> > > Also note that solaris doesn't seem to be handling this code any
> > > special, so there would be a difference between gcc + solaris and
> > > solstudio + solaris. Rather hypothetical case, I suppose, but still ;-)
> > > One of the arguments were that gcc is being used on other platforms
> > > than linux.
> > > 
> > > > You can also consider adding a capability check if you know that
> > > > versions of the compiler that should still work don't have the feature.
> > > 
> > > One clarification: Does a capability check mean doing this at the
> > > configure step or is there a way one has access to toolchain versions
> > > in make files?
> > > 
> > > Thanks,
> > > Severin
> > > 
> > > > /Erik
> > > > > Thanks,
> > > > > Severin
> > > > > 
> > > > > > /Erik
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > David
> > > > > > > > 
> > > > > > > > On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > Cross-posting this review-thread on core-libs-dev and build-dev as
> > > > > > > > > this
> > > > > > > > > is a build change, but affects fdlibm which is core-libs.
> > > > > > > > > 
> > > > > > > > > With JDK-8170153 optimization for fdlibm code has been turned on
> > > > > > > > > for
> > > > > > > > > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > > > > > > > > arches
> > > > > > > > > on Linux. I've not observed any precision issues. Is there a good
> > > > > > > > > reason to not use -O3 -ffp-contract=off everywhere?
> > > > > > > > > 
> > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416
> > > > > > > > > webrev:
> > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/ 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> > > > > > > > >              - Currently running through submit repo.
> > > > > > > > > 
> > > > > > > > > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > > > > > > > > for
> > > > > > > > > StrictMath:
> > > > > > > > > 
> > > > > > > > > Function      | before     | after
> > > > > > > > > ----------------------------------------------
> > > > > > > > > sin           | 0m33.382s  | 0m18.731s
> > > > > > > > > cos           | 0m31.562s  | 0m18.796s
> > > > > > > > > tan           | 0m33.657s  | 0m21.093s
> > > > > > > > > atan          | 0m5.714s   | 0m4.902s
> > > > > > > > > log           | 0m6.212s   | 0m4.439s
> > > > > > > > > log10         | 0m7.946s   | 0m5.543s
> > > > > > > > > sqrt          | 0m0.481s   | 0m0.449s
> > > > > > > > > cbrt          | 0m5.295s   | 0m5.214s
> > > > > > > > > tanh          | 0m1.404s   | 0m1.307s
> > > > > > > > > log1p         | 0m6.457s   | 0m5.131s
> > > > > > > > > IEEEremainder | 0m10.629s  | 0m6.048s
> > > > > > > > > atan2         | 0m8.037s   | 0m5.668s
> > > > > > > > > hypot         | 0m2.171s   | 0m2.147s
> > > > > > > > > 
> > > > > > > > > Thoughts?
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Severin
> > > > > > > > > 
> > > > > > > > > 
> > > > 
> > > > 
> 
> 


From erik.joelsson at oracle.com  Fri Sep  7 17:19:04 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 7 Sep 2018 10:19:04 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
Message-ID: <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>

On 2018-09-07 09:56, Severin Gehwolf wrote:
> On Fri, 2018-09-07 at 09:12 -0700, Erik Joelsson wrote:
>> To me it sounds like we want this flag if the toolchain is either gcc or
>> clang, so please make it conditional on that.
> Updated webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.02/
>
> It now only sets FDLIBM_CFLAGS if gcc supports it and builds fdlibm
> without opt if not. Otherwise it uses -O3 and -ffp-contract=off. If the
> toolchain is clang and on linux it always uses -O3 and -ffp-
> contract=off. The reason, I've done this in configure is a potential
> follow-up fix for hotspot via JDK-8210425 where the CFLAGS could get
> re-used. Thoughts?
Instead of checking for compiler version, you could simply use the 
FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and 
clang. We usually prefer this over version checks (unless a version is 
just known to be unstable with a certain flag, in which case a 
capability check will not work).

CoreLibrarkes.gmk:
43: I think "with" is superfluous

Otherwise I think this looks like the right direction.

/Erik
> Thanks,
> Severin
>
>> /Erik
>>> Thanks,
>>> David
>>>
>>>> Also note that solaris doesn't seem to be handling this code any
>>>> special, so there would be a difference between gcc + solaris and
>>>> solstudio + solaris. Rather hypothetical case, I suppose, but still ;-)
>>>> One of the arguments were that gcc is being used on other platforms
>>>> than linux.
>>>>
>>>>> You can also consider adding a capability check if you know that
>>>>> versions of the compiler that should still work don't have the feature.
>>>> One clarification: Does a capability check mean doing this at the
>>>> configure step or is there a way one has access to toolchain versions
>>>> in make files?
>>>>
>>>> Thanks,
>>>> Severin
>>>>
>>>>> /Erik
>>>>>> Thanks,
>>>>>> Severin
>>>>>>
>>>>>>> /Erik
>>>>>>>> Thanks,
>>>>>>>> Severin
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Cross-posting this review-thread on core-libs-dev and build-dev as
>>>>>>>>>> this
>>>>>>>>>> is a build change, but affects fdlibm which is core-libs.
>>>>>>>>>>
>>>>>>>>>> With JDK-8170153 optimization for fdlibm code has been turned on
>>>>>>>>>> for
>>>>>>>>>> ppc64 s390 and aarch64. This patch intends to turn it on on all
>>>>>>>>>> arches
>>>>>>>>>> on Linux. I've not observed any precision issues. Is there a good
>>>>>>>>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210416
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
>>>>>>>>>>               - Currently running through submit repo.
>>>>>>>>>>
>>>>>>>>>> A simple micro benchmark from JDK-8170153[1] shows these numbers
>>>>>>>>>> for
>>>>>>>>>> StrictMath:
>>>>>>>>>>
>>>>>>>>>> Function      | before     | after
>>>>>>>>>> ----------------------------------------------
>>>>>>>>>> sin           | 0m33.382s  | 0m18.731s
>>>>>>>>>> cos           | 0m31.562s  | 0m18.796s
>>>>>>>>>> tan           | 0m33.657s  | 0m21.093s
>>>>>>>>>> atan          | 0m5.714s   | 0m4.902s
>>>>>>>>>> log           | 0m6.212s   | 0m4.439s
>>>>>>>>>> log10         | 0m7.946s   | 0m5.543s
>>>>>>>>>> sqrt          | 0m0.481s   | 0m0.449s
>>>>>>>>>> cbrt          | 0m5.295s   | 0m5.214s
>>>>>>>>>> tanh          | 0m1.404s   | 0m1.307s
>>>>>>>>>> log1p         | 0m6.457s   | 0m5.131s
>>>>>>>>>> IEEEremainder | 0m10.629s  | 0m6.048s
>>>>>>>>>> atan2         | 0m8.037s   | 0m5.668s
>>>>>>>>>> hypot         | 0m2.171s   | 0m2.147s
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Severin
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>


From sean.mullan at oracle.com  Fri Sep  7 18:13:18 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Sep 2018 14:13:18 -0400
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: <10a18d9f-c40f-5e82-ab52-6f7cefccddff@oracle.com>

On 8/27/18 10:25 AM, Baesken, Matthias wrote:
>> 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 .

I think we should fix it as part of this issue. It shouldn't be hard and 
then we don't have to file another issue to fix it.

--Sean

From sean.mullan at oracle.com  Fri Sep  7 19:41:10 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Sep 2018 15:41:10 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <b197f112ef474462aa4fc6773676a636@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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: <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>

On 8/29/18 10:01 AM, Baesken, Matthias 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/

java/util/jar/Attributes.java

  469         return AccessController.doPrivileged(new 
PrivilegedAction<String>() {
  470             public String run() {
  471                 return file.getAbsolutePath() + ":" + lineNumber;
  472             }
  473         });

I have a serious concern with the code above.

With this change, untrusted code running under a SecurityManager could 
potentially create a JarFile on a non-absolute path ex: "foo.jar", and 
(somehow) cause an IOException to be thrown which would then reveal the 
absolute path of where the jar was located, and thus could reveal 
sensitive details about the system (ex: the user's home directory). It 
could still be hard to exploit, since it would have to be a known jar 
that exists, and you would then need to cause an IOException to be 
thrown, but it's still theoretically possible.

In short, this is a more general issue in that it may allow untrusted 
code to access something it couldn't have previously. new 
JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.

Granted this can only be done if the security property is enabled, but I 
believe this is not something administrators should have to know about 
their environment and account for when enabling this property.

The above code should be changed to return only what the caller provides 
to JarFile, which is the name of the file (without the full path).

--Sean

From igor.ignatyev at oracle.com  Fri Sep  7 22:11:33 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 7 Sep 2018 15:11:33 -0700
Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and
 JDKToolLauncher
Message-ID: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
> 327 lines changed: 13 ins; 270 del; 44 mod; 

Hi all,

could you please review the patch which removes jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively?

JBS: https://bugs.openjdk.java.net/browse/JDK-8182404
webrev: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
testing: tier1-3 + :jdk_svc

Thanks,
-- Igor

From weijun.wang at oracle.com  Fri Sep  7 23:58:59 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 8 Sep 2018 07:58:59 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
Message-ID: <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com>

In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). Maybe we can add some more detail in the java.security so an admin knows what exact impact it has.

--Max

> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 8/29/18 10:01 AM, Baesken, Matthias 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/
> 
> java/util/jar/Attributes.java
> 
> 469         return AccessController.doPrivileged(new PrivilegedAction<String>() {
> 470             public String run() {
> 471                 return file.getAbsolutePath() + ":" + lineNumber;
> 472             }
> 473         });
> 
> I have a serious concern with the code above.
> 
> With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible.
> 
> In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
> 
> Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property.
> 
> The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path).
> 
> --Sean


From alexey.menkov at oracle.com  Sat Sep  8 00:45:30 2018
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 7 Sep 2018 17:45:30 -0700
Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and
 JDKToolLauncher
In-Reply-To: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>
References: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>
Message-ID: <ee39472c-b0b6-10f2-23a2-090458ea5801@oracle.com>

Hi Igor,

Looks good.

--alex

On 09/07/2018 15:11, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
>> 327 lines changed: 13 ins; 270 del; 44 mod;
> 
> Hi all,
> 
> could you please review the patch which removes jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively?
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182404
> webrev: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
> testing: tier1-3 + :jdk_svc
> 
> Thanks,
> -- Igor
> 

From jcbeyler at google.com  Sat Sep  8 01:03:06 2018
From: jcbeyler at google.com (JC Beyler)
Date: Fri, 7 Sep 2018 18:03:06 -0700
Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and
 JDKToolLauncher
In-Reply-To: <ee39472c-b0b6-10f2-23a2-090458ea5801@oracle.com>
References: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>
 <ee39472c-b0b6-10f2-23a2-090458ea5801@oracle.com>
Message-ID: <CAF9BGByxz670LaZpNw-qFZnTPgLN7EVXer=3KfLCw3vFcf1Sow@mail.gmail.com>

Hi Igor,

Looks good to me as well, nice job :-)
Jc

On Fri, Sep 7, 2018 at 5:46 PM Alex Menkov <alexey.menkov at oracle.com> wrote:

> Hi Igor,
>
> Looks good.
>
> --alex
>
> On 09/07/2018 15:11, Igor Ignatyev wrote:
> > http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
> >> 327 lines changed: 13 ins; 270 del; 44 mod;
> >
> > Hi all,
> >
> > could you please review the patch which removes
> jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages
> w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively?
> >
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8182404
> > webrev:
> http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
> > testing: tier1-3 + :jdk_svc
> >
> > Thanks,
> > -- Igor
> >
>


-- 

Thanks,
Jc

From Alan.Bateman at oracle.com  Sat Sep  8 07:50:23 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 8 Sep 2018 08:50:23 +0100
Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and
 JDKToolLauncher
In-Reply-To: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>
References: <A0283C3A-3CF4-4812-9E00-5A26D78FB86D@oracle.com>
Message-ID: <e1e0e98b-e62d-3354-f425-f46cc4567db5@oracle.com>



On 07/09/2018 23:11, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html
>
I skimmed through the changes and they look okay. One test to check is 
PatchSystemModules as it looks like /lib/testlibrary can be dropped from 
its @library tag.

-Alan

From t.linkowski at gmail.com  Sat Sep  8 12:59:32 2018
From: t.linkowski at gmail.com (Tomasz Linkowski)
Date: Sat, 8 Sep 2018 14:59:32 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two other
 collectors
Message-ID: <CAD4YxQU_P76AV2BEg0GQdYxz2Xk42SnnCK0GB+KZoEAnz6MRXQ@mail.gmail.com>

Hello,

I'm responding to the thread at [1] (I'm not sure whether my message will
get appended to it) and the CSR at [2].

I stumbled here from StackOverflow where - indepedently of all the others -
I also came up with this type of "dual" *Collector* [3]. I named it
"collectingBoth" there but I'd like to suggest a slightly different name
here.

I believe that Zheka Kozlov made a great observation about similiarity to
"collectingAndThen" [4]. And it seems Brian Goetz favors the "AndThen"
suffix [5]. On the other hand, this new Collector differs from
"collectingAndThen" in that:
1) it hides the accumulation type parameters (A1, A2), and
2) it needs a few lower bounds on some of its type parameters.

All in all, I'd like to propose to name the method "collectingBothAndThen"
(or alternatively: "biCollectingAndThen".

As an aside, I'd like to suggest changing the name of the parameter from
"merger" to "biFinisher":
1) Peter Levart pointed out in [6] that "finisher" is already taken by the
Collector API (and it's true), but it didn't prevent "collectingAndThen"
from taking a "finisher" and then
calling: downstream.finisher().andThen(finisher)
2) note that in all other contexts "merger" represents a BinaryOperator
because it merges two values of the *same* type, and here the types of
merged values are different.

Complete signatures for comparison below:

*<T,A,R,RR> Collector<T,A,RR> collectingAndThen(*
*    Collector<T, A, R> downstream,*
*    Function<R, RR> finisher)*

*<T,R1,R2,R> Collector<T,?,R> collectingBothAndThen(*
*    Collector<? super T, ?, R1> downstream1,*
*    Collector<? super T, ?, R2> downstream2,*
*    BiFunction<? super R1, ? super R2, R> biFinisher)*


As to the other potential names, I must say:
- I'm not in favor of "teeingAndThen" nor all the duplex-related names (I
find them unintuitive, especially the "teeing" one),
- I really like "composite" and "compound" proposed by Stuart Marks [7]; it
seems that "compouding" could be both intuitive and adhering to the -ing
suffix convention

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054718.html
[2] https://bugs.openjdk.java.net/browse/JDK-8209685
[3] https://stackoverflow.com/a/52211175/2032415
[4]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053922.html
[5]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054736.html
[6]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054724.html
[7]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html

-- 
Regards,
Tomasz Linkowski

From sean.mullan at oracle.com  Sat Sep  8 13:42:06 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Sat, 8 Sep 2018 09:42:06 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com>
Message-ID: <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>

On 9/7/18 7:58 PM, Weijun Wang wrote:
> In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). 

If you are very familiar with a particular application and understand 
the risks associated with running it, then I agree that is ok. But 
security properties apply to all applications using that JDK, and so I 
don't always think it is practical for an admin to understand every type 
of application that may be using that JDK and whether or not enabling 
this property presents a risk.

> Maybe we can add some more detail in the java.security so an admin knows what exact impact it has.

It would be a slippery slope in my opinion. You would have to say 
something like: "enabling this property may allow untrusted code running 
under a SecurityManager to access sensitive information such as the 
user.home system property even if it has not been granted permission to 
do so."

I think we should consider not allowing this property to take effect if 
a SecurityManager is running.

--Sean

> 
> --Max
> 
>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
>>
>> java/util/jar/Attributes.java
>>
>> 469         return AccessController.doPrivileged(new PrivilegedAction<String>() {
>> 470             public String run() {
>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
>> 472             }
>> 473         });
>>
>> I have a serious concern with the code above.
>>
>> With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible.
>>
>> In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
>>
>> Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property.
>>
>> The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path).
>>
>> --Sean
> 

From weijun.wang at oracle.com  Sat Sep  8 15:42:56 2018
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sat, 8 Sep 2018 23:42:56 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co!
 m> <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
Message-ID: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>

Thinking about this again. Looks like the absolute path is not necessary. Even if there are multiple files using the same name, they will be in different directories, no matter absolute or relative. Suppose the jarPath info is used for debugging purpose mostly like the developer can find out what the current working directory is and can find the files. *Matthias*: Is the absolute path really necessary? Are you working on actual case?

As for the possible global effect of a security property, maybe we can emphasis that this is both a security property and system property, and if it?s just for one time use, it?s better to use a system property. 

BTW, does the existing value ?hostInfo? of the property have a similar problem?

Thanks
Max

>> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com> ???
>> 
>> On 9/7/18 7:58 PM, Weijun Wang wrote:
>> In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell).
> 
> If you are very familiar with a particular application and understand the risks associated with running it, then I agree that is ok. But security properties apply to all applications using that JDK, and so I don't always think it is practical for an admin to understand every type of application that may be using that JDK and whether or not enabling this property presents a risk.
> 
>> Maybe we can add some more detail in the java.security so an admin knows what exact impact it has.
> 
> It would be a slippery slope in my opinion. You would have to say something like: "enabling this property may allow untrusted code running under a SecurityManager to access sensitive information such as the user.home system property even if it has not been granted permission to do so."
> 
> I think we should consider not allowing this property to take effect if a SecurityManager is running.
> 
> --Sean
> 
>> --Max
>>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
>>> 
>>> java/util/jar/Attributes.java
>>> 
>>> 469         return AccessController.doPrivileged(new PrivilegedAction<String>() {
>>> 470             public String run() {
>>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
>>> 472             }
>>> 473         });
>>> 
>>> I have a serious concern with the code above.
>>> 
>>> With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible.
>>> 
>>> In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
>>> 
>>> Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property.
>>> 
>>> The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path).
>>> 
>>> --Sean


From martinrb at google.com  Sun Sep  9 00:34:03 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 8 Sep 2018 17:34:03 -0700
Subject: Question about libjava/childproc.c
In-Reply-To: <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
 <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
 <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>
Message-ID: <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>

On Wed, Sep 5, 2018 at 11:43 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> On Wed, Sep 5, 2018 at 6:43 PM, Martin Buchholz <martinrb at google.com>
> wrote:
>
> > So before the readdir loop we should set errno to 0.  Then when readdir
> > returns NULL, we should check whether errno is non-zero.
> >
>
> Note that if we fix this, we may run into errors which were hidden
> before, namely if we really accidentally did close the file descriptor
> used by opendir(). Currently, even if some file descriptors remain
> unclosed, that may not necessarily lead to an error. But with your
> suggested error handling we would straight away fail.
>
> Therefore I would combine both fixes - add readdir error handling and
> also change to fcntl(FD_CLOEXEC).
>
>
I support this plan.  We expect most file descriptors to already have
the FD_CLOEXEC
flag set, so a useful optimization is to set the flag only when not already
set.

Probably the code should be conditional on defined(FD_CLOEXEC).


> > ---
> >
> > We do have a way of reporting errno to the parent.  See
> WhyCantJohnnyExec.
>
> Ah I see.
>
> Btw, do you know what happens when we modify errno in a vforked child
> process? Would that not modify errno in the parent process too? (errno
> is probably implemented as thread local variable, and since the parent
> thread sleeps until we exec this may still be okay, or?).
>
>
It's a good question.  vfork is typically underspecified, so it is
plausible that changing errno in the child affects the parent.  I think we
should simply make sure that the parent code is robust against this (as it
typically is - you check errno when a system API has already returned an
indication of an error)


> ---
>
> A bit more background, if you are interested:
>
> A long time ago, at SAP we swapped Oracle's implementation of
> Runtime.exec on Unix against a completely homegrown one. The reason
> was that we needed a really robust implementation for our customers,
> and with the then current implementation we kept running into
> limitations and pathological corner cases. Especially on outlier
> platforms like HPUX or AS/400.
>
> This was long before OpenJDK existed, so there was no way for us to
> just fix the coding upstream.


In 2005 I was the primary maintainer of the subprocess code at Sun, and
there is a good chance you could have gotten changes in if you had asked me!


> But now there is, so at regular
> intervals I keep eyeing our implementation to check if we could merge.
>
> The main difference between our version and the upstream one is: we
> switched to vfork() for the obvious performance reasons. But since
> vfork() is scary we implemented the exec-twice-trick with a little
> in-between binary. The main purpose was to minimize the window between
> vfork() and the first exec(), where we operate inside the parent
> process memory. Everything "dangerous" - calling libc functions,
> scanning the proc file system, error handling, tracing etc - is
> deferred to after the first exec. And since that window is minimal,
> that also reduces the chance of signals in the child process harming
> the parent.
>
>
See discussion in src/java.base/unix/native/libjava/ProcessImpl_md.c


> Later Oracle introduced something very similar with the jspawnhelper.
> But I see that jspawnhelper is not used at all for the vfork() case,
> just for posix_spawn(), yes?
>

Implemented by other folks.  I was mostly happy with vfork.  I forget the
motivation to introduce  jspawnhelper, but I'm sure it's in the fossil
record somewhere!

From Alan.Bateman at oracle.com  Sun Sep  9 08:04:44 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 9 Sep 2018 09:04:44 +0100
Subject: Question about libjava/childproc.c
In-Reply-To: <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
 <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
 <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>
 <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>
Message-ID: <a80dc12f-163b-4415-7514-40812066db11@oracle.com>

On 09/09/2018 01:34, Martin Buchholz wrote:
> :
>
> See discussion in?src/java.base/unix/native/libjava/ProcessImpl_md.c
>
>     Later Oracle introduced something very similar with the jspawnhelper.
>     But I see that jspawnhelper is not used at all for the vfork() case,
>     just for posix_spawn(), yes?
>
>
> Implemented by other folks.? I was mostly happy with vfork.? I forget 
> the motivation to introduce jspawnhelper, but I'm sure it's in the 
> fossil record somewhere!
jpsawnhelper is to deal with chdir and threading issues that arise when 
using posix_spawn. The move to posix_spawn was motivated by eager 
allocation of swap when using fork. It was originally done for Solaris, 
then macOS, and I see the AIX implementation is declared to use 
posix_spawn too. Linux is using vfork and seems to be stable. Martin 
will probably remember a brief foray into clone(CLONE_VM) at one point 
but that didn't work out.

-Alan

From martinrb at google.com  Sun Sep  9 17:38:41 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 9 Sep 2018 10:38:41 -0700
Subject: Question about libjava/childproc.c
In-Reply-To: <a80dc12f-163b-4415-7514-40812066db11@oracle.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
 <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
 <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>
 <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>
 <a80dc12f-163b-4415-7514-40812066db11@oracle.com>
Message-ID: <CA+kOe09OfAO5UcumzvPgdQ=azdeYPE+FFsqfxQFJE5dHtvyHEg@mail.gmail.com>

On Sun, Sep 9, 2018 at 1:04 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 09/09/2018 01:34, Martin Buchholz wrote:
>
> :
>
> See discussion in src/java.base/unix/native/libjava/ProcessImpl_md.c
>
>
>> Later Oracle introduced something very similar with the jspawnhelper.
>> But I see that jspawnhelper is not used at all for the vfork() case,
>> just for posix_spawn(), yes?
>>
>
> Implemented by other folks.  I was mostly happy with vfork.  I forget the
> motivation to introduce  jspawnhelper, but I'm sure it's in the fossil
> record somewhere!
>
> jpsawnhelper is to deal with chdir and threading issues that arise when
> using posix_spawn. The move to posix_spawn was motivated by eager
> allocation of swap when using fork. It was originally done for Solaris,
> then macOS, and I see the AIX implementation is declared to use posix_spawn
> too. Linux is using vfork and seems to be stable. Martin will probably
> remember a brief foray into clone(CLONE_VM) at one point but that didn't
> work out.
>

Thanks.  I followed my own advice and re-read the comments in
ProcessImpl_md.c.

I now recall not paying full attention to the posix_spawn implementation
because I use Linux exclusively, where "my" vfork implementation works well.

It seems too late to add HP-UX support to OpenJDK, but if SAP are willing
to do the porting work I would support it (why didn't HP do it decades
ago?).  One decision to make for any Unix platform is which process
implementation strategy to use.

From amy.lu at oracle.com  Mon Sep 10 07:19:51 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 10 Sep 2018 15:19:51 +0800
Subject: [12] RFR of JDK-8209930: Refactor
 java/util/zip/ZipFile/deletetempjar.sh to plain java test
Message-ID: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>

test/jdk/java/util/zip/ZipFile/deletetempjar.sh

Please review this patch to refactor above shell script test to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8209930
webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/

Thanks,
Amy

From Alan.Bateman at oracle.com  Mon Sep 10 07:20:04 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 08:20:04 +0100
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: <fbb31c4c-c7f1-a837-d485-cd834d5f6917@oracle.com>

On 30/08/2018 10:06, vyom tewari wrote:
> Hi Chris,
>
> The refactored? java class (RunBasic.java) looks good to me.
Looks okay to me too but the file handling could be improved, e.g. no 
need to resolve path against ".", should specify the elements to Path.of 
so that they use the right separator for the platform.

-Alan

From Alan.Bateman at oracle.com  Mon Sep 10 07:27:12 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 08:27:12 +0100
Subject: [12] RFR of JDK-8209930: Refactor
 java/util/zip/ZipFile/deletetempjar.sh to plain java test
In-Reply-To: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>
References: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>
Message-ID: <84fb0c69-c795-7ded-93a1-3709b8c0caf3@oracle.com>



On 10/09/2018 08:19, Amy Lu wrote:
> test/jdk/java/util/zip/ZipFile/deletetempjar.sh
>
> Please review this patch to refactor above shell script test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8209930
> webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/
This okay as a replacement but it can be a bit fragile sometimes to use 
the output of the sub-process. Just thinking about warnings or other 
output in non-product builds that might be sent to stdout rather than 
stderr. An alternative would be DeleteTempJarTest to create a listener 
socket and have DeleteTempJar connect to send the file name - we can go 
there is any issues arise.

-Alan

From jai.forums2013 at gmail.com  Mon Sep 10 07:31:08 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 10 Sep 2018 13:01:08 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
Message-ID: <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>

Any other reviews? I'm not a committer, so I'll also need someone to
help sponsor this patch.

-Jaikiran


On 06/09/18 7:39 PM, Jaikiran Pai wrote:
> On 06/09/18 1:24 PM, Bernd Eckenfels wrote:
>> Yes you are right @apinote is aproperiate section (was confusing it with implnote).
>>
>> Still think a ?literal specified list? is no longer a good (as in canonical) usecase for that method.
>>
>> I used it in the past often to get a List for using toString() on it, but I guess even for that case List.of can be used instead now.
>>
>> So @see List#of and let the reader figure out when to use them?
> That sounds good to me. I've now updated it to reflect this change and
> the javadoc now looks as below. I've also attached the new updated patch.
>
> ??? /**
> ???? * 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
> ???? * 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
> ???? * @see List#of()
> ???? */
>
>
>
> -Jaikiran
>


From matthias.baesken at sap.com  Mon Sep 10 07:53:20 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 10 Sep 2018 07:53:20 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
Message-ID: <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>

Hello are you fine with  changing from  file.getAbsolutePath()    to   file.getName() ?


http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/share/classes/java/util/jar/Manifest.java.frames.html


206     static String getErrorPosition(String filename, final int lineNumber) {
 207         if (filename == null || !jarPathInExceptionText) {
 208             return "line " + lineNumber;
 209         }
 210 
 211         final File file = new File(filename);
 212         return AccessController.doPrivileged(new PrivilegedAction<String>() {
 213             public String run() {
 214                 return "manifest of " + file.getName() + ":" + lineNumber;
 215             }


Best regards, Matthias


> -----Original Message-----
> From: Wang Weijun <weijun.wang at oracle.com>
> Sent: Samstag, 8. September 2018 17:43
> To: Sean Mullan <sean.mullan at oracle.com>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
> <Alan.Bateman 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
> 
> Thinking about this again. Looks like the absolute path is not necessary. Even
> if there are multiple files using the same name, they will be in different
> directories, no matter absolute or relative. Suppose the jarPath info is used
> for debugging purpose mostly like the developer can find out what the
> current working directory is and can find the files. *Matthias*: Is the absolute
> path really necessary? Are you working on actual case?
> 
> As for the possible global effect of a security property, maybe we can
> emphasis that this is both a security property and system property, and if it?s
> just for one time use, it?s better to use a system property.
> 
> BTW, does the existing value ?hostInfo? of the property have a similar
> problem?
> 
> Thanks
> Max
> 
> >> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com> ?
> ??
> >>
> >> On 9/7/18 7:58 PM, Weijun Wang wrote:
> >> In my understanding, the author deliberately wants to show the absolute
> paths when there are multiple jar files with the same name (Ex: a jar hell).
> >
> > If you are very familiar with a particular application and understand the risks
> associated with running it, then I agree that is ok. But security properties
> apply to all applications using that JDK, and so I don't always think it is
> practical for an admin to understand every type of application that may be
> using that JDK and whether or not enabling this property presents a risk.
> >
> >> Maybe we can add some more detail in the java.security so an admin
> knows what exact impact it has.
> >
> > It would be a slippery slope in my opinion. You would have to say
> something like: "enabling this property may allow untrusted code running
> under a SecurityManager to access sensitive information such as the
> user.home system property even if it has not been granted permission to do
> so."
> >
> > I think we should consider not allowing this property to take effect if a
> SecurityManager is running.
> >
> > --Sean
> >
> >> --Max
> >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com>
> wrote:
> >>>
> >>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
> >>>
> >>> java/util/jar/Attributes.java
> >>>
> >>> 469         return AccessController.doPrivileged(new
> PrivilegedAction<String>() {
> >>> 470             public String run() {
> >>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
> >>> 472             }
> >>> 473         });
> >>>
> >>> I have a serious concern with the code above.
> >>>
> >>> With this change, untrusted code running under a SecurityManager
> could potentially create a JarFile on a non-absolute path ex: "foo.jar", and
> (somehow) cause an IOException to be thrown which would then reveal the
> absolute path of where the jar was located, and thus could reveal sensitive
> details about the system (ex: the user's home directory). It could still be hard
> to exploit, since it would have to be a known jar that exists, and you would
> then need to cause an IOException to be thrown, but it's still theoretically
> possible.
> >>>
> >>> In short, this is a more general issue in that it may allow untrusted code
> to access something it couldn't have previously. new
> JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
> >>>
> >>> Granted this can only be done if the security property is enabled, but I
> believe this is not something administrators should have to know about their
> environment and account for when enabling this property.
> >>>
> >>> The above code should be changed to return only what the caller
> provides to JarFile, which is the name of the file (without the full path).
> >>>
> >>> --Sean


From christoph.langer at sap.com  Mon Sep 10 08:04:25 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 10 Sep 2018 08:04:25 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>

Hi Matthias,

I think it would be enough to drop the privileged section and just return "filename" as is. (without conveting to a file object).

I also agree with Sean that the common parts of the new src/java.base/share/classes/sun/security/util/SecurityProperties.java should be aligned with src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, SocketExceptions calling SecurityProperties)

Best regards
Christoph


> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Baesken, Matthias
> Sent: Montag, 10. September 2018 09:53
> To: Wang Weijun <weijun.wang at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>
> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages during
> manifest parsing of jar archives
> 
> Hello are you fine with  changing from  file.getAbsolutePath()    to
> file.getName() ?
> 
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s
> hare/classes/java/util/jar/Manifest.java.frames.html
> 
> 
> 206     static String getErrorPosition(String filename, final int lineNumber) {
>  207         if (filename == null || !jarPathInExceptionText) {
>  208             return "line " + lineNumber;
>  209         }
>  210
>  211         final File file = new File(filename);
>  212         return AccessController.doPrivileged(new PrivilegedAction<String>()
> {
>  213             public String run() {
>  214                 return "manifest of " + file.getName() + ":" + lineNumber;
>  215             }
> 
> 
> Best regards, Matthias
> 
> 
> > -----Original Message-----
> > From: Wang Weijun <weijun.wang at oracle.com>
> > Sent: Samstag, 8. September 2018 17:43
> > To: Sean Mullan <sean.mullan at oracle.com>
> > Cc: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
> > <Alan.Bateman 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
> >
> > Thinking about this again. Looks like the absolute path is not necessary.
> Even
> > if there are multiple files using the same name, they will be in different
> > directories, no matter absolute or relative. Suppose the jarPath info is used
> > for debugging purpose mostly like the developer can find out what the
> > current working directory is and can find the files. *Matthias*: Is the
> absolute
> > path really necessary? Are you working on actual case?
> >
> > As for the possible global effect of a security property, maybe we can
> > emphasis that this is both a security property and system property, and if
> it?s
> > just for one time use, it?s better to use a system property.
> >
> > BTW, does the existing value ?hostInfo? of the property have a similar
> > problem?
> >
> > Thanks
> > Max
> >
> > >> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com> ?
> > ??
> > >>
> > >> On 9/7/18 7:58 PM, Weijun Wang wrote:
> > >> In my understanding, the author deliberately wants to show the
> absolute
> > paths when there are multiple jar files with the same name (Ex: a jar hell).
> > >
> > > If you are very familiar with a particular application and understand the
> risks
> > associated with running it, then I agree that is ok. But security properties
> > apply to all applications using that JDK, and so I don't always think it is
> > practical for an admin to understand every type of application that may be
> > using that JDK and whether or not enabling this property presents a risk.
> > >
> > >> Maybe we can add some more detail in the java.security so an admin
> > knows what exact impact it has.
> > >
> > > It would be a slippery slope in my opinion. You would have to say
> > something like: "enabling this property may allow untrusted code running
> > under a SecurityManager to access sensitive information such as the
> > user.home system property even if it has not been granted permission to
> do
> > so."
> > >
> > > I think we should consider not allowing this property to take effect if a
> > SecurityManager is running.
> > >
> > > --Sean
> > >
> > >> --Max
> > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com>
> > wrote:
> > >>>
> > >>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
> > >>>
> > >>> java/util/jar/Attributes.java
> > >>>
> > >>> 469         return AccessController.doPrivileged(new
> > PrivilegedAction<String>() {
> > >>> 470             public String run() {
> > >>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
> > >>> 472             }
> > >>> 473         });
> > >>>
> > >>> I have a serious concern with the code above.
> > >>>
> > >>> With this change, untrusted code running under a SecurityManager
> > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and
> > (somehow) cause an IOException to be thrown which would then reveal
> the
> > absolute path of where the jar was located, and thus could reveal sensitive
> > details about the system (ex: the user's home directory). It could still be
> hard
> > to exploit, since it would have to be a known jar that exists, and you would
> > then need to cause an IOException to be thrown, but it's still theoretically
> > possible.
> > >>>
> > >>> In short, this is a more general issue in that it may allow untrusted code
> > to access something it couldn't have previously. new
> > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
> > >>>
> > >>> Granted this can only be done if the security property is enabled, but I
> > believe this is not something administrators should have to know about
> their
> > environment and account for when enabling this property.
> > >>>
> > >>> The above code should be changed to return only what the caller
> > provides to JarFile, which is the name of the file (without the full path).
> > >>>
> > >>> --Sean


From magnus.ihse.bursie at oracle.com  Mon Sep 10 08:10:58 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Sep 2018 10:10:58 +0200
Subject: RFR: JDK-8059019 sdp.conf.template should move from unix to
 solaris
In-Reply-To: <bbd8cb3a-f9eb-7dab-192d-97b35ce5619d@oracle.com>
References: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>
 <bbd8cb3a-f9eb-7dab-192d-97b35ce5619d@oracle.com>
Message-ID: <26440c5b-46b6-9353-701e-f582cb5b64a3@oracle.com>



On 2018-09-05 15:26, Alan Bateman wrote:
> On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
>> The file sdp.conf.template is copied only when building for solaris, 
>> but it resides in the unix source directory.
> SDP is legacy now and we should probably think about removing it, esp. 
> with the rsocket support in the works.
>
> In the mean time, as the SDP support is compiled into libnet on Linux, 
> then we should copy the template in the Linux image too.

Updated patch, which copies the SDP template for linux too:

diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk
+++ b/make/copy/Copy-java.base.gmk
@@ -183,7 +183,7 @@

 ?TARGETS += $(COPY_NET_PROPERTIES)

-ifeq ($(OPENJDK_TARGET_OS), solaris)
+ifneq ($(filter $(OPENJDK_TARGET_OS), solaris linux), )
 ?? $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \
 ?????? FILES := 
$(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, 
\
 ?????? DEST := $(CONF_DST_DIR)/sdp, \


/Magnus


From matthias.baesken at sap.com  Mon Sep 10 08:21:09 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 10 Sep 2018 08:21:09 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
Message-ID: <VI1PR02MB43847916A4AEC6C746EA04AD93050@VI1PR02MB4384.eurprd02.prod.outlook.com>

> I think it would be enough to drop the privileged section and just return
> "filename" as is. (without conveting to a file object).

OK, any objections on this ?


> I also agree with Sean that the common parts of the new
> src/java.base/share/classes/sun/security/util/SecurityProperties.java should
> be aligned with
> src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is,
> SocketExceptions calling SecurityProperties)

OK I will include this in the next webrev .


Thanks, Matthias


> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 10. September 2018 10:04
> To: Baesken, Matthias <matthias.baesken at sap.com>; Wang Weijun
> <weijun.wang at oracle.com>; Sean Mullan <sean.mullan at oracle.com>
> Cc: 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
> 
> Hi Matthias,
> 
> I think it would be enough to drop the privileged section and just return
> "filename" as is. (without conveting to a file object).
> 
> I also agree with Sean that the common parts of the new
> src/java.base/share/classes/sun/security/util/SecurityProperties.java should
> be aligned with
> src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is,
> SocketExceptions calling SecurityProperties)
> 
> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> > Of Baesken, Matthias
> > Sent: Montag, 10. September 2018 09:53
> > To: Wang Weijun <weijun.wang at oracle.com>; Sean Mullan
> > <sean.mullan at oracle.com>
> > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> > Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages
> during
> > manifest parsing of jar archives
> >
> > Hello are you fine with  changing from  file.getAbsolutePath()    to
> > file.getName() ?
> >
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s
> > hare/classes/java/util/jar/Manifest.java.frames.html
> >
> >
> > 206     static String getErrorPosition(String filename, final int lineNumber) {
> >  207         if (filename == null || !jarPathInExceptionText) {
> >  208             return "line " + lineNumber;
> >  209         }
> >  210
> >  211         final File file = new File(filename);
> >  212         return AccessController.doPrivileged(new
> PrivilegedAction<String>()
> > {
> >  213             public String run() {
> >  214                 return "manifest of " + file.getName() + ":" + lineNumber;
> >  215             }
> >
> >
> > Best regards, Matthias
> >
> >
> > > -----Original Message-----
> > > From: Wang Weijun <weijun.wang at oracle.com>
> > > Sent: Samstag, 8. September 2018 17:43
> > > To: Sean Mullan <sean.mullan at oracle.com>
> > > Cc: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
> > > <Alan.Bateman 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
> > >
> > > Thinking about this again. Looks like the absolute path is not necessary.
> > Even
> > > if there are multiple files using the same name, they will be in different
> > > directories, no matter absolute or relative. Suppose the jarPath info is
> used
> > > for debugging purpose mostly like the developer can find out what the
> > > current working directory is and can find the files. *Matthias*: Is the
> > absolute
> > > path really necessary? Are you working on actual case?
> > >
> > > As for the possible global effect of a security property, maybe we can
> > > emphasis that this is both a security property and system property, and if
> > it?s
> > > just for one time use, it?s better to use a system property.
> > >
> > > BTW, does the existing value ?hostInfo? of the property have a similar
> > > problem?
> > >
> > > Thanks
> > > Max
> > >
> > > >> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com>
> ?
> > > ??
> > > >>
> > > >> On 9/7/18 7:58 PM, Weijun Wang wrote:
> > > >> In my understanding, the author deliberately wants to show the
> > absolute
> > > paths when there are multiple jar files with the same name (Ex: a jar
> hell).
> > > >
> > > > If you are very familiar with a particular application and understand the
> > risks
> > > associated with running it, then I agree that is ok. But security properties
> > > apply to all applications using that JDK, and so I don't always think it is
> > > practical for an admin to understand every type of application that may
> be
> > > using that JDK and whether or not enabling this property presents a risk.
> > > >
> > > >> Maybe we can add some more detail in the java.security so an admin
> > > knows what exact impact it has.
> > > >
> > > > It would be a slippery slope in my opinion. You would have to say
> > > something like: "enabling this property may allow untrusted code running
> > > under a SecurityManager to access sensitive information such as the
> > > user.home system property even if it has not been granted permission to
> > do
> > > so."
> > > >
> > > > I think we should consider not allowing this property to take effect if a
> > > SecurityManager is running.
> > > >
> > > > --Sean
> > > >
> > > >> --Max
> > > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com>
> > > wrote:
> > > >>>
> > > >>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
> > > >>>
> > > >>> java/util/jar/Attributes.java
> > > >>>
> > > >>> 469         return AccessController.doPrivileged(new
> > > PrivilegedAction<String>() {
> > > >>> 470             public String run() {
> > > >>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
> > > >>> 472             }
> > > >>> 473         });
> > > >>>
> > > >>> I have a serious concern with the code above.
> > > >>>
> > > >>> With this change, untrusted code running under a SecurityManager
> > > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and
> > > (somehow) cause an IOException to be thrown which would then reveal
> > the
> > > absolute path of where the jar was located, and thus could reveal
> sensitive
> > > details about the system (ex: the user's home directory). It could still be
> > hard
> > > to exploit, since it would have to be a known jar that exists, and you
> would
> > > then need to cause an IOException to be thrown, but it's still theoretically
> > > possible.
> > > >>>
> > > >>> In short, this is a more general issue in that it may allow untrusted
> code
> > > to access something it couldn't have previously. new
> > > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
> > > >>>
> > > >>> Granted this can only be done if the security property is enabled, but
> I
> > > believe this is not something administrators should have to know about
> > their
> > > environment and account for when enabling this property.
> > > >>>
> > > >>> The above code should be changed to return only what the caller
> > > provides to JarFile, which is the name of the file (without the full path).
> > > >>>
> > > >>> --Sean
> 


From aph at redhat.com  Mon Sep 10 09:05:18 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 10 Sep 2018 10:05:18 +0100
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
Message-ID: <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>

On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> Is there a good
> reason to not use -O3 -ffp-contract=off everywhere?

Is there a good reason to use -O3 rather than -O2? -O3 can bloat the
code which can increase cache pressure, which is not always noticeable
in benchmarks but hurts real-world programs. Unless benchmarks are
significantly better at -O3, -O2 is a good default choice.

-- 
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 xu.y.yin at oracle.com  Mon Sep 10 09:13:21 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Mon, 10 Sep 2018 17:13:21 +0800
Subject: [12] RFR 8209773: Refactor shell test
 javax/naming/module/basic.sh to java
In-Reply-To: <fbb31c4c-c7f1-a837-d485-cd834d5f6917@oracle.com>
References: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
 <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>
 <fbb31c4c-c7f1-a837-d485-cd834d5f6917@oracle.com>
Message-ID: <E6F12533-7262-482B-8AE7-550C8F8D5A70@oracle.com>

Thank you, Alan

Sure, I modified a little to remove ?.? and use Path.of as you suggested to improve file handling, minor revision as below, thanks

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

Regards,
Chris

> On 10 Sep 2018, at 3:20 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 30/08/2018 10:06, vyom tewari wrote:
>> Hi Chris,
>> 
>> The refactored  java class (RunBasic.java) looks good to me.
> Looks okay to me too but the file handling could be improved, e.g. no need to resolve path against ".", should specify the elements to Path.of so that they use the right separator for the platform.
> 
> -Alan


From sgehwolf at redhat.com  Mon Sep 10 09:27:53 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Sep 2018 11:27:53 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
Message-ID: <b973dbaa4711387feafefcbeb4e0c9d478f3966a.camel@redhat.com>

On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> 
> Is there a good reason to use -O3 rather than -O2?

Not sure. I was following what JDK-8170153 did, which was using
OPTIMIZATION := HIGH corresponding to -O3. cc'ing Gustavo. Gustavo,
would you know why HIGH was chosen over, LOW?

> -O3 can bloat the
> code which can increase cache pressure, which is not always noticeable
> in benchmarks but hurts real-world programs. Unless benchmarks are
> significantly better at -O3, -O2 is a good default choice.

OK, thanks! I'll re-test and change to LOW (-O2) if it gives similar
results.

Thanks,
Severin


From amy.lu at oracle.com  Mon Sep 10 09:40:07 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 10 Sep 2018 17:40:07 +0800
Subject: [12] RFR of JDK-8209930: Refactor
 java/util/zip/ZipFile/deletetempjar.sh to plain java test
In-Reply-To: <84fb0c69-c795-7ded-93a1-3709b8c0caf3@oracle.com>
References: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>
 <84fb0c69-c795-7ded-93a1-3709b8c0caf3@oracle.com>
Message-ID: <ddefad13-9137-4324-892b-7168514d0032@oracle.com>

On 2018/9/10 3:27 PM, Alan Bateman wrote:
>
>
> On 10/09/2018 08:19, Amy Lu wrote:
>> test/jdk/java/util/zip/ZipFile/deletetempjar.sh
>>
>> Please review this patch to refactor above shell script test to java.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209930
>> webrev: http://cr.openjdk.java.net/~amlu/8209930/webrev.00/
> This okay as a replacement but it can be a bit fragile sometimes to 
> use the output of the sub-process. Just thinking about warnings or 
> other output in non-product builds that might be sent to stdout rather 
> than stderr. An alternative would be DeleteTempJarTest to create a 
> listener socket and have DeleteTempJar connect to send the file name - 
> we can go there is any issues arise.

Good point!

How about to resolve it later in a separate issueto-be-filed?

Thanks,
Amy

>
> -Alan


From Alan.Bateman at oracle.com  Mon Sep 10 09:41:28 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 10:41:28 +0100
Subject: [12] RFR of JDK-8209930: Refactor
 java/util/zip/ZipFile/deletetempjar.sh to plain java test
In-Reply-To: <ddefad13-9137-4324-892b-7168514d0032@oracle.com>
References: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>
 <84fb0c69-c795-7ded-93a1-3709b8c0caf3@oracle.com>
 <ddefad13-9137-4324-892b-7168514d0032@oracle.com>
Message-ID: <eb8e0273-1c7a-89bb-3b1c-dc9673889149@oracle.com>



On 10/09/2018 10:40, Amy Lu wrote:
>
> Good point!
>
> How about to resolve it later in a separate issueto-be-filed?
Okay with me.

-Alan

From Alan.Bateman at oracle.com  Mon Sep 10 09:42:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 10:42:18 +0100
Subject: [12] RFR 8209773: Refactor shell test
 javax/naming/module/basic.sh to java
In-Reply-To: <E6F12533-7262-482B-8AE7-550C8F8D5A70@oracle.com>
References: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
 <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>
 <fbb31c4c-c7f1-a837-d485-cd834d5f6917@oracle.com>
 <E6F12533-7262-482B-8AE7-550C8F8D5A70@oracle.com>
Message-ID: <ab3c691b-5426-4321-4631-f8ff61c00571@oracle.com>



On 10/09/2018 10:13, Chris Yin wrote:
> Thank you, Alan
>
> Sure, I modified a little to remove ?.? and use Path.of as you suggested to improve file handling, minor revision as below, thanks
>
> http://cr.openjdk.java.net/~xyin/8209773/webrev.01/
>
>
The update looks okay to me.

-Alan

From sgehwolf at redhat.com  Mon Sep 10 10:29:57 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Sep 2018 12:29:57 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
Message-ID: <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>

Hi Erik,

On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
> Instead of checking for compiler version, you could simply use the 
> FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and 
> clang. We usually prefer this over version checks (unless a version is 
> just known to be unstable with a certain flag, in which case a 
> capability check will not work).

I see. Note JDK-8157358, though, which seems to have changed[1] the
build system to not use FLAGS_COMPILER_CHECK_ARGUMENTS as it seems to
break cross-compilation. It's not used at the moment. Do you still want
me to use it?

> CoreLibrarkes.gmk:
> 43: I think "with" is superfluous

Thanks, fixed locally.

> Otherwise I think this looks like the right direction.

Glad to hear that.

Thanks,
Severin

[1] http://hg.openjdk.java.net/jdk9/jdk9/rev/f51004322fbe


From chris.hegarty at oracle.com  Mon Sep 10 12:00:10 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Sep 2018 13:00:10 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
Message-ID: <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>

Vyom,

The NPE is originating from the finally block of the LdapClient
`authenticate` method. In the finally block there is an attempt
to restore the "read" timeout, since it was changed earlier in
`authenticate`, to reflect the connect timeout value, since the
subsequent operation(s) are considered part of the connect phase.

An unsolicited message may close the connection during
authenticate, which is does and LdapClient.ldapBind throws
"javax.naming.CommunicationException: Request: 1 cancelled". The
finally block is then executed and the previous exception is
effectively throw away when the NPE is encountered.

If we agree that such behaviour is reasonable ( and I think it
most likely is ), then the finally block needs to be more
defensive - check that conn is not null. It makes no sense to
attempt to reset the read timeout if conn is null.

With the following change, then the CommunicationException will
be thrown from `authenticate`. I think this is the behaviour we
want, no?


--- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
+++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
@@ -297,7 +297,8 @@
              conn.setV3(isLdapv3);
              return res;
          } finally {
-            conn.readTimeout = readTimeout;
+            if (conn != null)
+                conn.readTimeout = readTimeout;
          }
      }


-Chris.


On 07/09/18 17:47, Daniel Fuchs wrote:
> Hi Vyom,
> 
> Please see inline... I've elided some parts...
> 
> On 07/09/2018 10:11, vyom tewari wrote:
>> On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
>>> So what we see here is actually a race between an open
>>> connection being retrieved from the pool, and the server
>>> deciding to close that connection.
>>> The connection/client is retrieved from the pool, then
>>> unfortunately closed by the server after having been selected
>>> for the next operation.
>>>
>> I checked? the code and i did not found any problem. Both "get" and 
>> "removePooledConnection" are "synchronized" so there should not be any 
>> problem(concurrency issue) here.
> 
> I'm referring to this pattern (in forceClose):
> 
>  ??????????? conn.cleanup(null, false);
>  ??????????? conn = null;
> 
>  ??????????? if (cleanPool) {
>  ??????????????? pcb.removePooledConnection(this);
>  ??????????? }
> 
> The connection is cleaned up, then nulled, then only removed
> from the pool. I'm questioning whether the first thing to do would
> be to remove the connection from the pool, to reduce the time window
> in which the client could be retrieved from the pool by another
> thread while forceClose is in process.
> 
> I am not sure what side effect this could have - as I haven't
> studied the code that retrieves the client from the pool,
> but I'm wondering whether that's worth exploring.
> 
>> As you said server is closing the same connection which is retrieved 
>> from pool which? is correct but this should not throw unintentional NPE.
> 
> Agreed.
> 
>> In LdapClient, we set the "Ldapclient.conn" to explicitly null 
>> asynchronously after we remove the connection from pool and which is 
>> creating the NPE.
>>
>> LdapClient does not set `Ldapclient.conn` to null if connection is not 
>> pooled.
> 
> Really? That's not what I see... Am I missing something?
> 
>  >> [...]
>>> If so will leaving the 'conn' field assigned ensure that
>>> the retry happens, or will new InitialDirContext() fail
>>> with some other exception because the connection has
>>> been closed? Or does the code simply assume that asynchronous
>>> closing of the connection by the server can only happen while
>>> it's sitting idle in the pool?
>>>
>> ??I don't know if retrying is feasible in 'IntialDirContext' but if we 
>> leave 'LdapClient.conn' assigned then we will get 
>> "javax.naming.CommunicationException" which tells that, underline 
>> connection is closed. I am not 100% sure if this is right approach but 
>> if we set 'LdapClient.conn' to null asynchronously then we will hit NPE.
> 
> OK - that's good to know. I agree that CommunicationException is
> better than NPE. If so then not nulling the connection
> is at least an improvement.
> But this would deserve a comment in the code, I think.
> More below...
> 
>>> I wonder if some other mechanism could be used to reduce
>>> and hopefully eliminate the time window in which the race
>>> could appear. For instance taking the connection out of
>>> the pool before closing it, instead of closing it before
>>> taking it out of the pool, etc...
>>>
>> Changing order will not help, i think closing the? same connection is 
>> not a problem? but setting `LdapClient.conn'? to null asynchronously 
>> is causing NPE.
> 
> Yes - I agree that setting conn to null is problematic.
> I wonder why it's set to null. Maybe in an attempt to
> make it eligible for GC earlier?
> 
> If that's not the issue, then I would suggest making it
> final (AFAICS it's only set to non-null once) and cleaning
> up the code that tests for conn == null.
> 
> If GC is the issue, then the best you can do is probably
> only set it to null when the client is not pooled.
> 
> And if we could reduce the time window in which a thread
> could get a stale client from the pool that might be good
> too?
> 
> Is there anyway we could somehow add a test that reproduce
> the NPE?
> 
> best regards,
> 
> -- daniel
> 
> [...]
> 
>>>>> 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.
> [...]

From Alan.Bateman at oracle.com  Mon Sep 10 12:03:54 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 13:03:54 +0100
Subject: RFR: JDK-8059019 sdp.conf.template should move from unix to
 solaris
In-Reply-To: <26440c5b-46b6-9353-701e-f582cb5b64a3@oracle.com>
References: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>
 <bbd8cb3a-f9eb-7dab-192d-97b35ce5619d@oracle.com>
 <26440c5b-46b6-9353-701e-f582cb5b64a3@oracle.com>
Message-ID: <4fcd379f-5890-3789-24c2-88a35ae2088a@oracle.com>



On 10/09/2018 09:10, Magnus Ihse Bursie wrote:
> :
>
> Updated patch, which copies the SDP template for linux too:
>
> diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
> --- a/make/copy/Copy-java.base.gmk
> +++ b/make/copy/Copy-java.base.gmk
> @@ -183,7 +183,7 @@
>
> ?TARGETS += $(COPY_NET_PROPERTIES)
>
> -ifeq ($(OPENJDK_TARGET_OS), solaris)
> +ifneq ($(filter $(OPENJDK_TARGET_OS), solaris linux), )
> ?? $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \
> ?????? FILES := 
> $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, 
> \
> ?????? DEST := $(CONF_DST_DIR)/sdp, \
This looks okay.

-Alan

From sgehwolf at redhat.com  Mon Sep 10 12:40:50 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Sep 2018 14:40:50 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
Message-ID: <4e013aea972fc5aa9cda18eec87f93c3632dd30a.camel@redhat.com>

On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
> On 2018-09-07 09:56, Severin Gehwolf wrote:
> > On Fri, 2018-09-07 at 09:12 -0700, Erik Joelsson wrote:
> > > To me it sounds like we want this flag if the toolchain is either gcc or
> > > clang, so please make it conditional on that.
> > 
> > Updated webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.02/
> > 
> > It now only sets FDLIBM_CFLAGS if gcc supports it and builds fdlibm
> > without opt if not. Otherwise it uses -O3 and -ffp-contract=off. If the
> > toolchain is clang and on linux it always uses -O3 and -ffp-
> > contract=off. The reason, I've done this in configure is a potential
> > follow-up fix for hotspot via JDK-8210425 where the CFLAGS could get
> > re-used. Thoughts?
> 
> Instead of checking for compiler version, you could simply use the 
> FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and 
> clang. We usually prefer this over version checks (unless a version is 
> just known to be unstable with a certain flag, in which case a 
> capability check will not work).
> 
> CoreLibrarkes.gmk:
> 43: I think "with" is superfluous
> 
> Otherwise I think this looks like the right direction.

Latest webrev with Andrew Haley's suggestion to use -O2. I'm observing
similar performance numbers than -O3. I haven't changed to the
FLAGS_COMPILER_CHECK_ARGUMENTS macro as I'm not clear this is safe to
do at this point without breaking cross-compilation:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.03/

Thanks,
Severin


From sgehwolf at redhat.com  Mon Sep 10 12:43:24 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Sep 2018 14:43:24 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
Message-ID: <e33d747b2afb3eb51811fd48a351acab2e8324c9.camel@redhat.com>

Hi Andrew,

On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> 
> Is there a good reason to use -O3 rather than -O2? -O3 can bloat the
> code which can increase cache pressure, which is not always noticeable
> in benchmarks but hurts real-world programs. Unless benchmarks are
> significantly better at -O3, -O2 is a good default choice.

As I'm not seeing significant difference between -O2 and -O3, I've
switched to LOW (corresponding to -O2) as default. See:
http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023165.html

Thanks,
Severin


From gromero at linux.vnet.ibm.com  Mon Sep 10 13:15:52 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 10 Sep 2018 10:15:52 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b973dbaa4711387feafefcbeb4e0c9d478f3966a.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
 <b973dbaa4711387feafefcbeb4e0c9d478f3966a.camel@redhat.com>
Message-ID: <799fd248-17c0-d10b-f266-871cd5e8613f@linux.vnet.ibm.com>

Hi Severin,

On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
> On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
>> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
>>> Is there a good
>>> reason to not use -O3 -ffp-contract=off everywhere?
>>
>> Is there a good reason to use -O3 rather than -O2?
> 
> Not sure. I was following what JDK-8170153 did, which was using
> OPTIMIZATION := HIGH corresponding to -O3. cc'ing Gustavo. Gustavo,
> would you know why HIGH was chosen over, LOW?

I don't remember exactly, but at least for ppc64 I discussed that a bit with
the toolchain folks (also regarding the precision issue, etc) and they never
said anything against using -O3. Unfortunately it was long time ago so I
don't remember exactly the numbers on ppc64 for -O2 to check if it was
worse and so I selected -O3 instead.


>> -O3 can bloat the
>> code which can increase cache pressure, which is not always noticeable
>> in benchmarks but hurts real-world programs. Unless benchmarks are
>> significantly better at -O3, -O2 is a good default choice.
> 
> OK, thanks! I'll re-test and change to LOW (-O2) if it gives similar
> results.

That's interesting. Andrew, do you mean bloat in the sense of final code size
(for instance, due to unrolling), right?

BTW (I just remembered that), on RISC the lack of optimization hurts way more
than the lack of optimization on CISC, so I recall that it puzzled me the fact
that turning on the optimization on x86_64 did not change much the scenario,
contrary to the conspicuous gains on on ppc64 when turning on the optimization.
I took me some time so to understand that the optimization flag was the culprit
(a much simpler case lucky), because I tried first to profile and optimize the
fdlibm code (after extracting it from JVM for detailed analysis) and only after
getting to a dead end I turned to look at simpler causes.

Are you checking the difference between -O2 and -O3 only on x86_64?


Best regards,
Gustavo


From sgehwolf at redhat.com  Mon Sep 10 13:26:40 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Sep 2018 15:26:40 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <799fd248-17c0-d10b-f266-871cd5e8613f@linux.vnet.ibm.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
 <b973dbaa4711387feafefcbeb4e0c9d478f3966a.camel@redhat.com>
 <799fd248-17c0-d10b-f266-871cd5e8613f@linux.vnet.ibm.com>
Message-ID: <1624e12ce587717f778465de5cb32e16f907cf7f.camel@redhat.com>

Hi Gustavo,

On Mon, 2018-09-10 at 10:15 -0300, Gustavo Romero wrote:
> Hi Severin,
> 
> On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
> > On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
> > > On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
> > > > Is there a good
> > > > reason to not use -O3 -ffp-contract=off everywhere?
> > > 
> > > Is there a good reason to use -O3 rather than -O2?
> > 
> > Not sure. I was following what JDK-8170153 did, which was using
> > OPTIMIZATION := HIGH corresponding to -O3. cc'ing Gustavo. Gustavo,
> > would you know why HIGH was chosen over, LOW?
> 
> I don't remember exactly, but at least for ppc64 I discussed that a bit with
> the toolchain folks (also regarding the precision issue, etc) and they never
> said anything against using -O3. Unfortunately it was long time ago so I
> don't remember exactly the numbers on ppc64 for -O2 to check if it was
> worse and so I selected -O3 instead.
> 
> 
> > > -O3 can bloat the
> > > code which can increase cache pressure, which is not always noticeable
> > > in benchmarks but hurts real-world programs. Unless benchmarks are
> > > significantly better at -O3, -O2 is a good default choice.
> > 
> > OK, thanks! I'll re-test and change to LOW (-O2) if it gives similar
> > results.
> 
> That's interesting. Andrew, do you mean bloat in the sense of final code size
> (for instance, due to unrolling), right?
> 
> BTW (I just remembered that), on RISC the lack of optimization hurts way more
> than the lack of optimization on CISC, so I recall that it puzzled me the fact
> that turning on the optimization on x86_64 did not change much the scenario,
> contrary to the conspicuous gains on on ppc64 when turning on the optimization.
> I took me some time so to understand that the optimization flag was the culprit
> (a much simpler case lucky), because I tried first to profile and optimize the
> fdlibm code (after extracting it from JVM for detailed analysis) and only after
> getting to a dead end I turned to look at simpler causes.
> 
> Are you checking the difference between -O2 and -O3 only on x86_64?

So far yes. I'll see if I can get access to a ppc64 machine to check
there as well. The plan is to run (some) TCK on a patched x86_64 build
too.

Thanks,
Severin


From matthias.baesken at sap.com  Mon Sep 10 13:59:08 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 10 Sep 2018 13:59:08 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
Message-ID: <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>

New webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/


- SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties
- Attributes  getErrorPosition   adjusted  (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.)

After the changes I wonder - should  the  jarPath  category   be  renamed to jarFile  (or something else) ?


Best regards, Matthias

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 10. September 2018 10:04
> To: Baesken, Matthias <matthias.baesken at sap.com>; Wang Weijun
> <weijun.wang at oracle.com>; Sean Mullan <sean.mullan at oracle.com>
> Cc: 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
> 
> Hi Matthias,
> 
> I think it would be enough to drop the privileged section and just return
> "filename" as is. (without conveting to a file object).
> 
> I also agree with Sean that the common parts of the new
> src/java.base/share/classes/sun/security/util/SecurityProperties.java should
> be aligned with
> src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is,
> SocketExceptions calling SecurityProperties)
> 
> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> > Of Baesken, Matthias
> > Sent: Montag, 10. September 2018 09:53
> > To: Wang Weijun <weijun.wang at oracle.com>; Sean Mullan
> > <sean.mullan at oracle.com>
> > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> > Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages
> during
> > manifest parsing of jar archives
> >
> > Hello are you fine with  changing from  file.getAbsolutePath()    to
> > file.getName() ?
> >
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s
> > hare/classes/java/util/jar/Manifest.java.frames.html
> >
> >
> > 206     static String getErrorPosition(String filename, final int lineNumber) {
> >  207         if (filename == null || !jarPathInExceptionText) {
> >  208             return "line " + lineNumber;
> >  209         }
> >  210
> >  211         final File file = new File(filename);
> >  212         return AccessController.doPrivileged(new
> PrivilegedAction<String>()
> > {
> >  213             public String run() {
> >  214                 return "manifest of " + file.getName() + ":" + lineNumber;
> >  215             }
> >
> >
> > Best regards, Matthias
> >
> >
> > > -----Original Message-----
> > > From: Wang Weijun <weijun.wang at oracle.com>
> > > Sent: Samstag, 8. September 2018 17:43
> > > To: Sean Mullan <sean.mullan at oracle.com>
> > > Cc: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
> > > <Alan.Bateman 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
> > >
> > > Thinking about this again. Looks like the absolute path is not necessary.
> > Even
> > > if there are multiple files using the same name, they will be in different
> > > directories, no matter absolute or relative. Suppose the jarPath info is
> used
> > > for debugging purpose mostly like the developer can find out what the
> > > current working directory is and can find the files. *Matthias*: Is the
> > absolute
> > > path really necessary? Are you working on actual case?
> > >
> > > As for the possible global effect of a security property, maybe we can
> > > emphasis that this is both a security property and system property, and if
> > it?s
> > > just for one time use, it?s better to use a system property.
> > >
> > > BTW, does the existing value ?hostInfo? of the property have a similar
> > > problem?
> > >
> > > Thanks
> > > Max
> > >
> > > >> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com>
> ?
> > > ??
> > > >>
> > > >> On 9/7/18 7:58 PM, Weijun Wang wrote:
> > > >> In my understanding, the author deliberately wants to show the
> > absolute
> > > paths when there are multiple jar files with the same name (Ex: a jar
> hell).
> > > >
> > > > If you are very familiar with a particular application and understand the
> > risks
> > > associated with running it, then I agree that is ok. But security properties
> > > apply to all applications using that JDK, and so I don't always think it is
> > > practical for an admin to understand every type of application that may
> be
> > > using that JDK and whether or not enabling this property presents a risk.
> > > >
> > > >> Maybe we can add some more detail in the java.security so an admin
> > > knows what exact impact it has.
> > > >
> > > > It would be a slippery slope in my opinion. You would have to say
> > > something like: "enabling this property may allow untrusted code running
> > > under a SecurityManager to access sensitive information such as the
> > > user.home system property even if it has not been granted permission to
> > do
> > > so."
> > > >
> > > > I think we should consider not allowing this property to take effect if a
> > > SecurityManager is running.
> > > >
> > > > --Sean
> > > >
> > > >> --Max
> > > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com>
> > > wrote:
> > > >>>
> > > >>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
> > > >>>
> > > >>> java/util/jar/Attributes.java
> > > >>>
> > > >>> 469         return AccessController.doPrivileged(new
> > > PrivilegedAction<String>() {
> > > >>> 470             public String run() {
> > > >>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
> > > >>> 472             }
> > > >>> 473         });
> > > >>>
> > > >>> I have a serious concern with the code above.
> > > >>>
> > > >>> With this change, untrusted code running under a SecurityManager
> > > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and
> > > (somehow) cause an IOException to be thrown which would then reveal
> > the
> > > absolute path of where the jar was located, and thus could reveal
> sensitive
> > > details about the system (ex: the user's home directory). It could still be
> > hard
> > > to exploit, since it would have to be a known jar that exists, and you
> would
> > > then need to cause an IOException to be thrown, but it's still theoretically
> > > possible.
> > > >>>
> > > >>> In short, this is a more general issue in that it may allow untrusted
> code
> > > to access something it couldn't have previously. new
> > > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
> > > >>>
> > > >>> Granted this can only be done if the security property is enabled, but
> I
> > > believe this is not something administrators should have to know about
> > their
> > > environment and account for when enabling this property.
> > > >>>
> > > >>> The above code should be changed to return only what the caller
> > > provides to JarFile, which is the name of the file (without the full path).
> > > >>>
> > > >>> --Sean
> 


From amy.lu at oracle.com  Mon Sep 10 14:03:04 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 10 Sep 2018 22:03:04 +0800
Subject: [12] RFR of JDK-8209930: Refactor
 java/util/zip/ZipFile/deletetempjar.sh to plain java test
In-Reply-To: <eb8e0273-1c7a-89bb-3b1c-dc9673889149@oracle.com>
References: <7e0d53a0-d682-642f-078c-9a6e3299ace3@oracle.com>
 <84fb0c69-c795-7ded-93a1-3709b8c0caf3@oracle.com>
 <ddefad13-9137-4324-892b-7168514d0032@oracle.com>
 <eb8e0273-1c7a-89bb-3b1c-dc9673889149@oracle.com>
Message-ID: <c88ad7c0-208a-d62e-e4e2-07c3662fa676@oracle.com>

On 2018/9/10 5:41 PM, Alan Bateman wrote:
>
> On 10/09/2018 10:40, Amy Lu wrote:
>>
>> Good point!
>>
>> How about to resolve it later in a separate issueto-be-filed?
> Okay with me.
>
> -Alan
Thank you Alan!

Pushed, and created JDK-8210548 as follow up.

Thanks,
Amy

From sean.mullan at oracle.com  Mon Sep 10 14:24:29 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 10 Sep 2018 10:24:29 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
Message-ID: <ecf51b50-b5b2-9a91-f140-f5bf7e131fc2@oracle.com>

On 9/8/18 11:42 AM, Wang Weijun wrote:
> Thinking about this again. Looks like the absolute path is not necessary. Even if there are multiple files using the same name, they will be in different directories, no matter absolute or relative. Suppose the jarPath info is used for debugging purpose mostly like the developer can find out what the current working directory is and can find the files. *Matthias*: Is the absolute path really necessary? Are you working on actual case?
> 
> As for the possible global effect of a security property, maybe we can emphasis that this is both a security property and system property, and if it?s just for one time use, it?s better to use a system property.
> 
> BTW, does the existing value ?hostInfo? of the property have a similar problem?

No. In that case, the sensitive data (IP address) is provided by the 
caller, so there is no leakage of sensitive data from trusted code that 
it is calling.

--Sean

From sean.mullan at oracle.com  Mon Sep 10 14:26:07 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 10 Sep 2018 10:26:07 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB43847916A4AEC6C746EA04AD93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB43847916A4AEC6C746EA04AD93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <4adc8e90-a307-380c-3535-e4201bf60311@oracle.com>

On 9/10/18 4:21 AM, Baesken, Matthias wrote:
>> I think it would be enough to drop the privileged section and just return
>> "filename" as is. (without conveting to a file object).
> 
> OK, any objections on this ?

No, this is fine with me.

--Sean

From weijun.wang at oracle.com  Mon Sep 10 14:31:25 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 10 Sep 2018 22:31:25 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <9E7E3778-37D4-4ACF-8892-854783B54997@oracle.com>



> On Sep 10, 2018, at 9:59 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/

Looks fine to me.

> 
> - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties
> - Attributes  getErrorPosition   adjusted  (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.)
> 
> After the changes I wonder - should  the  jarPath  category   be  renamed to jarFile  (or something else) ?

jarFile seems to be an instance of JarFile. I don't think jarPath has any problem.

Thanks
Max

> 
> 
> Best regards, Matthias
> 
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Montag, 10. September 2018 10:04
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Wang Weijun
>> <weijun.wang at oracle.com>; Sean Mullan <sean.mullan at oracle.com>
>> Cc: 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
>> 
>> Hi Matthias,
>> 
>> I think it would be enough to drop the privileged section and just return
>> "filename" as is. (without conveting to a file object).
>> 
>> I also agree with Sean that the common parts of the new
>> src/java.base/share/classes/sun/security/util/SecurityProperties.java should
>> be aligned with
>> src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is,
>> SocketExceptions calling SecurityProperties)
>> 
>> Best regards
>> Christoph
>> 
>> 
>>> -----Original Message-----
>>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>>> Of Baesken, Matthias
>>> Sent: Montag, 10. September 2018 09:53
>>> To: Wang Weijun <weijun.wang at oracle.com>; Sean Mullan
>>> <sean.mullan at oracle.com>
>>> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>>> Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages
>> during
>>> manifest parsing of jar archives
>>> 
>>> Hello are you fine with  changing from  file.getAbsolutePath()    to
>>> file.getName() ?
>>> 
>>> 
>>> 
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s
>>> hare/classes/java/util/jar/Manifest.java.frames.html
>>> 
>>> 
>>> 206     static String getErrorPosition(String filename, final int lineNumber) {
>>> 207         if (filename == null || !jarPathInExceptionText) {
>>> 208             return "line " + lineNumber;
>>> 209         }
>>> 210
>>> 211         final File file = new File(filename);
>>> 212         return AccessController.doPrivileged(new
>> PrivilegedAction<String>()
>>> {
>>> 213             public String run() {
>>> 214                 return "manifest of " + file.getName() + ":" + lineNumber;
>>> 215             }
>>> 
>>> 
>>> Best regards, Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Wang Weijun <weijun.wang at oracle.com>
>>>> Sent: Samstag, 8. September 2018 17:43
>>>> To: Sean Mullan <sean.mullan at oracle.com>
>>>> Cc: Baesken, Matthias <matthias.baesken at sap.com>; Alan Bateman
>>>> <Alan.Bateman 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
>>>> 
>>>> Thinking about this again. Looks like the absolute path is not necessary.
>>> Even
>>>> if there are multiple files using the same name, they will be in different
>>>> directories, no matter absolute or relative. Suppose the jarPath info is
>> used
>>>> for debugging purpose mostly like the developer can find out what the
>>>> current working directory is and can find the files. *Matthias*: Is the
>>> absolute
>>>> path really necessary? Are you working on actual case?
>>>> 
>>>> As for the possible global effect of a security property, maybe we can
>>>> emphasis that this is both a security property and system property, and if
>>> it?s
>>>> just for one time use, it?s better to use a system property.
>>>> 
>>>> BTW, does the existing value ?hostInfo? of the property have a similar
>>>> problem?
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>>>> ? 2018?9?8??21:42?Sean Mullan <sean.mullan at oracle.com>
>> ?
>>>> ??
>>>>>> 
>>>>>> On 9/7/18 7:58 PM, Weijun Wang wrote:
>>>>>> In my understanding, the author deliberately wants to show the
>>> absolute
>>>> paths when there are multiple jar files with the same name (Ex: a jar
>> hell).
>>>>> 
>>>>> If you are very familiar with a particular application and understand the
>>> risks
>>>> associated with running it, then I agree that is ok. But security properties
>>>> apply to all applications using that JDK, and so I don't always think it is
>>>> practical for an admin to understand every type of application that may
>> be
>>>> using that JDK and whether or not enabling this property presents a risk.
>>>>> 
>>>>>> Maybe we can add some more detail in the java.security so an admin
>>>> knows what exact impact it has.
>>>>> 
>>>>> It would be a slippery slope in my opinion. You would have to say
>>>> something like: "enabling this property may allow untrusted code running
>>>> under a SecurityManager to access sensitive information such as the
>>>> user.home system property even if it has not been granted permission to
>>> do
>>>> so."
>>>>> 
>>>>> I think we should consider not allowing this property to take effect if a
>>>> SecurityManager is running.
>>>>> 
>>>>> --Sean
>>>>> 
>>>>>> --Max
>>>>>>> On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mullan at oracle.com>
>>>> wrote:
>>>>>>> 
>>>>>>> On 8/29/18 10:01 AM, Baesken, Matthias 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/
>>>>>>> 
>>>>>>> java/util/jar/Attributes.java
>>>>>>> 
>>>>>>> 469         return AccessController.doPrivileged(new
>>>> PrivilegedAction<String>() {
>>>>>>> 470             public String run() {
>>>>>>> 471                 return file.getAbsolutePath() + ":" + lineNumber;
>>>>>>> 472             }
>>>>>>> 473         });
>>>>>>> 
>>>>>>> I have a serious concern with the code above.
>>>>>>> 
>>>>>>> With this change, untrusted code running under a SecurityManager
>>>> could potentially create a JarFile on a non-absolute path ex: "foo.jar", and
>>>> (somehow) cause an IOException to be thrown which would then reveal
>>> the
>>>> absolute path of where the jar was located, and thus could reveal
>> sensitive
>>>> details about the system (ex: the user's home directory). It could still be
>>> hard
>>>> to exploit, since it would have to be a known jar that exists, and you
>> would
>>>> then need to cause an IOException to be thrown, but it's still theoretically
>>>> possible.
>>>>>>> 
>>>>>>> In short, this is a more general issue in that it may allow untrusted
>> code
>>>> to access something it couldn't have previously. new
>>>> JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
>>>>>>> 
>>>>>>> Granted this can only be done if the security property is enabled, but
>> I
>>>> believe this is not something administrators should have to know about
>>> their
>>>> environment and account for when enabling this property.
>>>>>>> 
>>>>>>> The above code should be changed to return only what the caller
>>>> provides to JarFile, which is the name of the file (without the full path).
>>>>>>> 
>>>>>>> --Sean
>> 
> 


From sean.mullan at oracle.com  Mon Sep 10 14:35:18 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 10 Sep 2018 10:35:18 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>

On 9/10/18 9:59 AM, Baesken, Matthias wrote:
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
> 
> 
> - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties
> - Attributes  getErrorPosition   adjusted  (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.)
> 
> After the changes I wonder - should  the  jarPath  category   be  renamed to jarFile  (or something else) ?

Yes, renaming it to "jarFile" makes more sense. You will need to update 
the CSR with this change too.

A few other comments:

- java/util/jar/Manifest.java

   62     // name of the corresponding jar archive if available.
   63     private String jarFilename;

You can mark this final.

- sun/net/util/SocketExceptions.java

   33 import java.security.Security;

This import is no longer needed.

--Sean



From daniel.fuchs at oracle.com  Mon Sep 10 14:38:36 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 10 Sep 2018 15:38:36 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
Message-ID: <17fb5865-a7ac-273e-68f7-4b3f0e18ad2d@oracle.com>

Nice find Chris.

But I have to wonder why the NPE wasn't thrown at the
very beginning of `authenticate` namely one of these
two lines:

         int readTimeout = conn.readTimeout;
         conn.readTimeout = conn.connectTimeout;

which happen to be called even before ensureOpen() is
called a few lines later!

cheers,

-- daniel

On 10/09/2018 13:00, Chris Hegarty wrote:
> Vyom,
> 
> The NPE is originating from the finally block of the LdapClient
> `authenticate` method. In the finally block there is an attempt
> to restore the "read" timeout, since it was changed earlier in
> `authenticate`, to reflect the connect timeout value, since the
> subsequent operation(s) are considered part of the connect phase.
> 
> An unsolicited message may close the connection during
> authenticate, which is does and LdapClient.ldapBind throws
> "javax.naming.CommunicationException: Request: 1 cancelled". The
> finally block is then executed and the previous exception is
> effectively throw away when the NPE is encountered.
> 
> If we agree that such behaviour is reasonable ( and I think it
> most likely is ), then the finally block needs to be more
> defensive - check that conn is not null. It makes no sense to
> attempt to reset the read timeout if conn is null.
> 
> With the following change, then the CommunicationException will
> be thrown from `authenticate`. I think this is the behaviour we
> want, no?
> 
> 
> --- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
> +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
> @@ -297,7 +297,8 @@
>  ???????????? conn.setV3(isLdapv3);
>  ???????????? return res;
>  ???????? } finally {
> -??????????? conn.readTimeout = readTimeout;
> +??????????? if (conn != null)
> +??????????????? conn.readTimeout = readTimeout;
>  ???????? }
>  ???? }
> 
> 
> -Chris.

From weijun.wang at oracle.com  Mon Sep 10 14:42:50 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 10 Sep 2018 22:42:50 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
Message-ID: <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>



> On Sep 10, 2018, at 10:35 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
>> After the changes I wonder - should  the  jarPath  category   be  renamed to jarFile  (or something else) ?
> 
> Yes, renaming it to "jarFile" makes more sense. You will need to update the CSR with this change too.

Well, maybe either is OK.

I am still thinking that one day we could make this more precise, for example:

   /path/to/lib.jar!META-INF/MANIFEST.MF:23
   /path/to/lib.jar!META-INF/SIGNER.SF:34

The name should (at least vaguely) cover these info.

--Max


From christoph.langer at sap.com  Mon Sep 10 14:46:58 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 10 Sep 2018 14:46:58 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
Message-ID: <b5b0967f76e5460fbee2564ec1560179@sap.com>

Hi Sean, Max,

do you think we need property jdk.includeInExceptions=jar<File/Path> at all, if we don't resolve the absolute path?

@Matthias:
small remark to the code:
src/java.base/share/classes/sun/security/util/SecurityProperties.java
36     public static String privilegeGetOverridable(String propName) {

Should that method really be public? At the moment it doesn't seem to be used outside of SecurityProperties.

Best regards
Christoph

> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Montag, 10. September 2018 16:43
> To: Sean Mullan <sean.mullan at oracle.com>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; Langer, Christoph
> <christoph.langer at sap.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 Sep 10, 2018, at 10:35 PM, Sean Mullan <sean.mullan at oracle.com>
> wrote:
> >
> >> After the changes I wonder - should  the  jarPath  category   be  renamed
> to jarFile  (or something else) ?
> >
> > Yes, renaming it to "jarFile" makes more sense. You will need to update the
> CSR with this change too.
> 
> Well, maybe either is OK.
> 
> I am still thinking that one day we could make this more precise, for example:
> 
>    /path/to/lib.jar!META-INF/MANIFEST.MF:23
>    /path/to/lib.jar!META-INF/SIGNER.SF:34
> 
> The name should (at least vaguely) cover these info.
> 
> --Max


From vyom.tewari at oracle.com  Mon Sep 10 14:53:10 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Mon, 10 Sep 2018 20:23:10 +0530
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
Message-ID: <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>



On Monday 10 September 2018 05:30 PM, Chris Hegarty wrote:
> Vyom,
>
> The NPE is originating from the finally block of the LdapClient
> `authenticate` method. In the finally block there is an attempt
> to restore the "read" timeout, since it was changed earlier in
> `authenticate`, to reflect the connect timeout value, since the
> subsequent operation(s) are considered part of the connect phase.
>
> An unsolicited message may close the connection during
> authenticate, which is does and LdapClient.ldapBind throws
> "javax.naming.CommunicationException: Request: 1 cancelled". The
> finally block is then executed and the previous exception is
> effectively throw away when the NPE is encountered.
>
> If we agree that such behaviour is reasonable ( and I think it
> most likely is ), then the finally block needs to be more
> defensive - check that conn is not null. It makes no sense to
> attempt to reset the read timeout if conn is null.
>
> With the following change, then the CommunicationException will
> be thrown from `authenticate`. I think this is the behaviour we
> want, no?
>
Yes , this will definitely solve this NPE issue but we may hit NPE other 
places as well because we are setting 'LdapClient.com' to null 
asynchronously.
Vyom
>
> --- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
> +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
> @@ -297,7 +297,8 @@
> ???????????? conn.setV3(isLdapv3);
> ???????????? return res;
> ???????? } finally {
> -??????????? conn.readTimeout = readTimeout;
> +??????????? if (conn != null)
> +??????????????? conn.readTimeout = readTimeout;
> ???????? }
> ???? }
>
>
> -Chris.
>
>
> On 07/09/18 17:47, Daniel Fuchs wrote:
>> Hi Vyom,
>>
>> Please see inline... I've elided some parts...
>>
>> On 07/09/2018 10:11, vyom tewari wrote:
>>> On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
>>>> So what we see here is actually a race between an open
>>>> connection being retrieved from the pool, and the server
>>>> deciding to close that connection.
>>>> The connection/client is retrieved from the pool, then
>>>> unfortunately closed by the server after having been selected
>>>> for the next operation.
>>>>
>>> I checked? the code and i did not found any problem. Both "get" and 
>>> "removePooledConnection" are "synchronized" so there should not be 
>>> any problem(concurrency issue) here.
>>
>> I'm referring to this pattern (in forceClose):
>>
>> ???????????? conn.cleanup(null, false);
>> ???????????? conn = null;
>>
>> ???????????? if (cleanPool) {
>> ???????????????? pcb.removePooledConnection(this);
>> ???????????? }
>>
>> The connection is cleaned up, then nulled, then only removed
>> from the pool. I'm questioning whether the first thing to do would
>> be to remove the connection from the pool, to reduce the time window
>> in which the client could be retrieved from the pool by another
>> thread while forceClose is in process.
>>
>> I am not sure what side effect this could have - as I haven't
>> studied the code that retrieves the client from the pool,
>> but I'm wondering whether that's worth exploring.
>>
>>> As you said server is closing the same connection which is retrieved 
>>> from pool which? is correct but this should not throw unintentional 
>>> NPE.
>>
>> Agreed.
>>
>>> In LdapClient, we set the "Ldapclient.conn" to explicitly null 
>>> asynchronously after we remove the connection from pool and which is 
>>> creating the NPE.
>>>
>>> LdapClient does not set `Ldapclient.conn` to null if connection is 
>>> not pooled.
>>
>> Really? That's not what I see... Am I missing something?
>>
>> ?>> [...]
>>>> If so will leaving the 'conn' field assigned ensure that
>>>> the retry happens, or will new InitialDirContext() fail
>>>> with some other exception because the connection has
>>>> been closed? Or does the code simply assume that asynchronous
>>>> closing of the connection by the server can only happen while
>>>> it's sitting idle in the pool?
>>>>
>>> ??I don't know if retrying is feasible in 'IntialDirContext' but if 
>>> we leave 'LdapClient.conn' assigned then we will get 
>>> "javax.naming.CommunicationException" which tells that, underline 
>>> connection is closed. I am not 100% sure if this is right approach 
>>> but if we set 'LdapClient.conn' to null asynchronously then we will 
>>> hit NPE.
>>
>> OK - that's good to know. I agree that CommunicationException is
>> better than NPE. If so then not nulling the connection
>> is at least an improvement.
>> But this would deserve a comment in the code, I think.
>> More below...
>>
>>>> I wonder if some other mechanism could be used to reduce
>>>> and hopefully eliminate the time window in which the race
>>>> could appear. For instance taking the connection out of
>>>> the pool before closing it, instead of closing it before
>>>> taking it out of the pool, etc...
>>>>
>>> Changing order will not help, i think closing the? same connection 
>>> is not a problem? but setting `LdapClient.conn'? to null 
>>> asynchronously is causing NPE.
>>
>> Yes - I agree that setting conn to null is problematic.
>> I wonder why it's set to null. Maybe in an attempt to
>> make it eligible for GC earlier?
>>
>> If that's not the issue, then I would suggest making it
>> final (AFAICS it's only set to non-null once) and cleaning
>> up the code that tests for conn == null.
>>
>> If GC is the issue, then the best you can do is probably
>> only set it to null when the client is not pooled.
>>
>> And if we could reduce the time window in which a thread
>> could get a stale client from the pool that might be good
>> too?
>>
>> Is there anyway we could somehow add a test that reproduce
>> the NPE?
>>
>> best regards,
>>
>> -- daniel
>>
>> [...]
>>
>>>>>> 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.
>> [...]


From weijun.wang at oracle.com  Mon Sep 10 14:57:15 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 10 Sep 2018 22:57:15 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <b5b0967f76e5460fbee2564ec1560179@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
Message-ID: <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>



> On Sep 10, 2018, at 10:46 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Sean, Max,
> 
> do you think we need property jdk.includeInExceptions=jar<File/Path> at all, if we don't resolve the absolute path?

I think so. File path is still sensitive.

In fact, I tend to believe people usually use absolute paths for JAR files (or maybe made absolute by using a file:// URL somewhere inside JDK). Do you really see relative jar paths while testing this code change?

> 
> @Matthias:
> small remark to the code:
> src/java.base/share/classes/sun/security/util/SecurityProperties.java
> 36     public static String privilegeGetOverridable(String propName) {
> 
> Should that method really be public? At the moment it doesn't seem to be used outside of SecurityProperties.

I like it to be public. There are quite some other such system/security properties (Ex: jdk.serialFilter) that can make use of this method.

Thanks
Max

> 
> Best regards
> Christoph


From chris.hegarty at oracle.com  Mon Sep 10 15:32:29 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Sep 2018 16:32:29 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
 <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
Message-ID: <57ec4dbb-3855-7d16-9d70-3203a0b823b4@oracle.com>

Vyom,

You are correct, the change that I proposed is minimal
and some fragility still remains.

I talked with Daniel, walked through the code one more
time, and I am now convinced that your original proposal
is correct ( since the pooling is at the level of
LdapClient, rather than at the level of Connection ).

Can I also suggest:
  1) Remove the null assignments, rather commenting them
     out.
  2) Make Connection `conn` final.
  3) Remove all null checks for conn ( since it can no
     longer be null ).

-Chris.

On 10/09/18 15:53, vyom tewari wrote:
> 
> 
> On Monday 10 September 2018 05:30 PM, Chris Hegarty wrote:
>> Vyom,
>>
>> The NPE is originating from the finally block of the LdapClient
>> `authenticate` method. In the finally block there is an attempt
>> to restore the "read" timeout, since it was changed earlier in
>> `authenticate`, to reflect the connect timeout value, since the
>> subsequent operation(s) are considered part of the connect phase.
>>
>> An unsolicited message may close the connection during
>> authenticate, which is does and LdapClient.ldapBind throws
>> "javax.naming.CommunicationException: Request: 1 cancelled". The
>> finally block is then executed and the previous exception is
>> effectively throw away when the NPE is encountered.
>>
>> If we agree that such behaviour is reasonable ( and I think it
>> most likely is ), then the finally block needs to be more
>> defensive - check that conn is not null. It makes no sense to
>> attempt to reset the read timeout if conn is null.
>>
>> With the following change, then the CommunicationException will
>> be thrown from `authenticate`. I think this is the behaviour we
>> want, no?
>>
> Yes , this will definitely solve this NPE issue but we may hit NPE other 
> places as well because we are setting 'LdapClient.com' to null 
> asynchronously.
> Vyom
>>
>> --- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
>> +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java
>> @@ -297,7 +297,8 @@
>> ???????????? conn.setV3(isLdapv3);
>> ???????????? return res;
>> ???????? } finally {
>> -??????????? conn.readTimeout = readTimeout;
>> +??????????? if (conn != null)
>> +??????????????? conn.readTimeout = readTimeout;
>> ???????? }
>> ???? }
>>
>>
>> -Chris.
>>
>>
>> On 07/09/18 17:47, Daniel Fuchs wrote:
>>> Hi Vyom,
>>>
>>> Please see inline... I've elided some parts...
>>>
>>> On 07/09/2018 10:11, vyom tewari wrote:
>>>> On Tuesday 04 September 2018 08:13 PM, Daniel Fuchs wrote:
>>>>> So what we see here is actually a race between an open
>>>>> connection being retrieved from the pool, and the server
>>>>> deciding to close that connection.
>>>>> The connection/client is retrieved from the pool, then
>>>>> unfortunately closed by the server after having been selected
>>>>> for the next operation.
>>>>>
>>>> I checked? the code and i did not found any problem. Both "get" and 
>>>> "removePooledConnection" are "synchronized" so there should not be 
>>>> any problem(concurrency issue) here.
>>>
>>> I'm referring to this pattern (in forceClose):
>>>
>>> ???????????? conn.cleanup(null, false);
>>> ???????????? conn = null;
>>>
>>> ???????????? if (cleanPool) {
>>> ???????????????? pcb.removePooledConnection(this);
>>> ???????????? }
>>>
>>> The connection is cleaned up, then nulled, then only removed
>>> from the pool. I'm questioning whether the first thing to do would
>>> be to remove the connection from the pool, to reduce the time window
>>> in which the client could be retrieved from the pool by another
>>> thread while forceClose is in process.
>>>
>>> I am not sure what side effect this could have - as I haven't
>>> studied the code that retrieves the client from the pool,
>>> but I'm wondering whether that's worth exploring.
>>>
>>>> As you said server is closing the same connection which is retrieved 
>>>> from pool which? is correct but this should not throw unintentional 
>>>> NPE.
>>>
>>> Agreed.
>>>
>>>> In LdapClient, we set the "Ldapclient.conn" to explicitly null 
>>>> asynchronously after we remove the connection from pool and which is 
>>>> creating the NPE.
>>>>
>>>> LdapClient does not set `Ldapclient.conn` to null if connection is 
>>>> not pooled.
>>>
>>> Really? That's not what I see... Am I missing something?
>>>
>>> ?>> [...]
>>>>> If so will leaving the 'conn' field assigned ensure that
>>>>> the retry happens, or will new InitialDirContext() fail
>>>>> with some other exception because the connection has
>>>>> been closed? Or does the code simply assume that asynchronous
>>>>> closing of the connection by the server can only happen while
>>>>> it's sitting idle in the pool?
>>>>>
>>>> ??I don't know if retrying is feasible in 'IntialDirContext' but if 
>>>> we leave 'LdapClient.conn' assigned then we will get 
>>>> "javax.naming.CommunicationException" which tells that, underline 
>>>> connection is closed. I am not 100% sure if this is right approach 
>>>> but if we set 'LdapClient.conn' to null asynchronously then we will 
>>>> hit NPE.
>>>
>>> OK - that's good to know. I agree that CommunicationException is
>>> better than NPE. If so then not nulling the connection
>>> is at least an improvement.
>>> But this would deserve a comment in the code, I think.
>>> More below...
>>>
>>>>> I wonder if some other mechanism could be used to reduce
>>>>> and hopefully eliminate the time window in which the race
>>>>> could appear. For instance taking the connection out of
>>>>> the pool before closing it, instead of closing it before
>>>>> taking it out of the pool, etc...
>>>>>
>>>> Changing order will not help, i think closing the? same connection 
>>>> is not a problem? but setting `LdapClient.conn'? to null 
>>>> asynchronously is causing NPE.
>>>
>>> Yes - I agree that setting conn to null is problematic.
>>> I wonder why it's set to null. Maybe in an attempt to
>>> make it eligible for GC earlier?
>>>
>>> If that's not the issue, then I would suggest making it
>>> final (AFAICS it's only set to non-null once) and cleaning
>>> up the code that tests for conn == null.
>>>
>>> If GC is the issue, then the best you can do is probably
>>> only set it to null when the client is not pooled.
>>>
>>> And if we could reduce the time window in which a thread
>>> could get a stale client from the pool that might be good
>>> too?
>>>
>>> Is there anyway we could somehow add a test that reproduce
>>> the NPE?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> [...]
>>>
>>>>>>> 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.
>>> [...]
> 

From daniel.fuchs at oracle.com  Mon Sep 10 15:33:49 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 10 Sep 2018 16:33:49 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
 <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
Message-ID: <a481f947-637e-4576-176d-8f4b3767f6c2@oracle.com>

On 10/09/2018 15:53, vyom tewari wrote:
> Yes , this will definitely solve this NPE issue but we may hit NPE other 
> places as well because we are setting 'LdapClient.com' to null 
> asynchronously.

I agree with Vyom here.

Other solutions that have been investigated - such as only
setting the connection to null when its ref count reaches zero
now seem to complex (read: too risky because over the complexity
threshold) to me.

Maybe the best thing to do here is to stick to Vyom original's
idea, but declare conn final and do all the necessary (small)
cleanup that goes with it? Possibly also add a comment saying
that CommunicationException will be thrown if some other thread
uses the LdapClient after forceClose has been closed...

best regards,

-- daniel


From erik.joelsson at oracle.com  Mon Sep 10 16:17:50 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Sep 2018 09:17:50 -0700
Subject: RFR: JDK-8059019 sdp.conf.template should move from unix to
 solaris
In-Reply-To: <26440c5b-46b6-9353-701e-f582cb5b64a3@oracle.com>
References: <870ba337-98d0-612f-acd8-6f9907225fbb@oracle.com>
 <bbd8cb3a-f9eb-7dab-192d-97b35ce5619d@oracle.com>
 <26440c5b-46b6-9353-701e-f582cb5b64a3@oracle.com>
Message-ID: <85f9795f-3e37-5854-77ef-16974b13087a@oracle.com>

Looks good.

/Erik


On 2018-09-10 01:10, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-05 15:26, Alan Bateman wrote:
>> On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
>>> The file sdp.conf.template is copied only when building for solaris, 
>>> but it resides in the unix source directory.
>> SDP is legacy now and we should probably think about removing it, 
>> esp. with the rsocket support in the works.
>>
>> In the mean time, as the SDP support is compiled into libnet on 
>> Linux, then we should copy the template in the Linux image too.
>
> Updated patch, which copies the SDP template for linux too:
>
> diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
> --- a/make/copy/Copy-java.base.gmk
> +++ b/make/copy/Copy-java.base.gmk
> @@ -183,7 +183,7 @@
>
> ?TARGETS += $(COPY_NET_PROPERTIES)
>
> -ifeq ($(OPENJDK_TARGET_OS), solaris)
> +ifneq ($(filter $(OPENJDK_TARGET_OS), solaris linux), )
> ?? $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \
> ?????? FILES := 
> $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, 
> \
> ?????? DEST := $(CONF_DST_DIR)/sdp, \
>
>
> /Magnus
>


From erik.joelsson at oracle.com  Mon Sep 10 16:29:57 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Sep 2018 09:29:57 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
Message-ID: <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>

I see. I was not aware of that issue, but we clearly need to file a bug 
for it and fix it. In this case I think it's fine to us the macro however.

/Erik


On 2018-09-10 03:29, Severin Gehwolf wrote:
> Hi Erik,
>
> On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
>> Instead of checking for compiler version, you could simply use the
>> FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and
>> clang. We usually prefer this over version checks (unless a version is
>> just known to be unstable with a certain flag, in which case a
>> capability check will not work).
> I see. Note JDK-8157358, though, which seems to have changed[1] the
> build system to not use FLAGS_COMPILER_CHECK_ARGUMENTS as it seems to
> break cross-compilation. It's not used at the moment. Do you still want
> me to use it?
>
>> CoreLibrarkes.gmk:
>> 43: I think "with" is superfluous
> Thanks, fixed locally.
>
>> Otherwise I think this looks like the right direction.
> Glad to hear that.
>
> Thanks,
> Severin
>
> [1] http://hg.openjdk.java.net/jdk9/jdk9/rev/f51004322fbe
>


From erik.joelsson at oracle.com  Mon Sep 10 16:35:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Sep 2018 09:35:09 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
Message-ID: <339bcd32-56cf-4ba9-8d6b-cacba31f94db@oracle.com>

I've filed JDK-8210551.

/Erik


On 2018-09-10 09:29, Erik Joelsson wrote:
> I see. I was not aware of that issue, but we clearly need to file a 
> bug for it and fix it. In this case I think it's fine to us the macro 
> however.
>
> /Erik
>
>
> On 2018-09-10 03:29, Severin Gehwolf wrote:
>> Hi Erik,
>>
>> On Fri, 2018-09-07 at 10:19 -0700, Erik Joelsson wrote:
>>> Instead of checking for compiler version, you could simply use the
>>> FLAGS_COMPILER_CHECK_ARGUMENTS macro. This would apply to both gcc and
>>> clang. We usually prefer this over version checks (unless a version is
>>> just known to be unstable with a certain flag, in which case a
>>> capability check will not work).
>> I see. Note JDK-8157358, though, which seems to have changed[1] the
>> build system to not use FLAGS_COMPILER_CHECK_ARGUMENTS as it seems to
>> break cross-compilation. It's not used at the moment. Do you still want
>> me to use it?
>>
>>> CoreLibrarkes.gmk:
>>> 43: I think "with" is superfluous
>> Thanks, fixed locally.
>>
>>> Otherwise I think this looks like the right direction.
>> Glad to hear that.
>>
>> Thanks,
>> Severin
>>
>> [1] http://hg.openjdk.java.net/jdk9/jdk9/rev/f51004322fbe
>>
>


From Roger.Riggs at Oracle.com  Mon Sep 10 16:54:44 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Sep 2018 12:54:44 -0400
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <7d6bb15b-6ba5-42d5-7769-095bb9cb77a1@oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
 <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
 <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
 <7d6bb15b-6ba5-42d5-7769-095bb9cb77a1@oracle.com>
Message-ID: <13faf62f-9c31-e7ca-d7d4-bec89b139833@Oracle.com>

Hi Ivan,

Thanks for the suggestion.
Webrev updated:

 ?? http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/

Thanks, Roger

On 9/4/2018 3:38 PM, Ivan Gerasimov wrote:
> Thank you Roger!
>
> I'm not sure if it plays any significant role, but an unnecessary call 
> to nanoTime() after wait(delay) could be avoided with the code like this:
>
> ??? if (millis > 0) {
> ??????? if (isAlive()) {
> ??????????? final long startTime = System.nanoTime();
> ??????????? long delay = millis;
> ??????????? do {
> ??????????????? wait(delay);
> ??????????? } while (isAlive() && (delay = millis - 
> TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime)) > 0);
> ??????? }
> ??? } else if (millis == 0) {
>
>
> With kind regards,
> Ivan
>
>
> On 9/4/18 12:02 PM, Roger Riggs wrote:
>> Hi Martin, Ivan,
>>
>> Thanks for the suggestions.
>>
>> Update in place:
>> http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>>
>> On 8/29/2018 5:36 PM, Martin Buchholz wrote:
>>> 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.
>>>
>> Not trivial since a long cannot hold the combined time of 
>> millis(long) and nanos (long) in a TimeUnit(Nanos)
>> and the cumulative wait time needs to be measured by System.nanoTime().
>>
>>> 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
>> ok
>>>
>>> (I prefer the variable name "startTime")
>> ok
>>>
>>> (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))
>> ok,
>>>
>>> (I would reorder clauses to first check the common case millis > 0, 
>>> then millis == 0, last the error case millis < 0)
>> ok
>>>
>>> (it's a bad API that millis < 0 is an error)
>> too late for a behavior change though I suppose its in the direction 
>> of not getting error instead of the opposite....
>>
>>
>> An Observation:
>>
>> Join(ms) and join(ms, ns) might wait a bit longer than strictly 
>> necessary because the bottom out in Object.wait(ms).
>> It might be better if both ended up calling Object.wait(ms, ns).
>> But since Object.wait(ms,ns) rounds up to Object.wait(ms) that won't 
>> make a difference and to take advantage
>> of a finer clock resolution would mean native/vm changes to support 
>> object.wait(ms, ns).
>>
>> I'm inclined to address only the immediate issues raised in the early 
>> return and the clock dependency now.
>>
>> (BTW, I found no tests for Thread.sleep or .join.)
>>
>> Thanks, Roger
>>
>>>
>>>
>>> On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <Roger.Riggs at oracle.com 
>>> <mailto: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/
>>> <http://cr.openjdk.java.net/%7Erriggs/webrev-thread-early-8098798/>
>>>
>>> ??? Thanks, Roger
>>>
>>>
>>
>>
>


From mandy.chung at oracle.com  Mon Sep 10 17:53:16 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 10 Sep 2018 10:53:16 -0700
Subject: Review Request: JDK-8210502: jdeps does not handle properly on
 analyzing a mixture of MR JARs and non-MR JARs
Message-ID: <413f5a60-cb43-05c8-aa18-cd85a0161536@oracle.com>

To analyze class dependencies of a multi-release JAR file,
jdeps --multi-release option must be specified so that only
entries of the specified version will be analyzed.

This is to fix a bug in jdeps that fails when it is given
both MR JARs and non-MR JARs.? --multi-release option should
be accepted for non-MR JAR files and all unversioned entries
will be analyzed.? The fix is trivial; just remove the check.

Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210502/webrev.00

Mandy

From Alan.Bateman at oracle.com  Mon Sep 10 18:05:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 19:05:18 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <50ed4716-b76e-6557-1146-03084776c160@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
Message-ID: <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>

On 20/08/2018 16:18, Andrew Dinn wrote:
> 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/
>
>
The updated JEP looks much better.

I realize we've been through several iterations on this but I'm now 
wondering if the MappedByteBuffer is the right API. As you've shown, 
it's straight forward to map a region of NVM and use the existing API, 
I'm just not sure if it's the right API. I think I'd like to see a few 
examples of how the API might be used. ByteBuffers aren't intended for 
use by concurrent threads and I just wonder if the examples might need 
that. I also wonder if there is a possible connection with work in 
Project Panama and whether it's worth exploring if its scopes and 
pointers could be used to backed by NVM. The Risks and Assumption 
section mentions the 2GB limit which is another reminder that the MBB 
API may not be the right API.

The 2-arg force method to msync a region make sense? although it might 
be more consistent for the second parameter to be the length than the 
end offset.

A detail for later is whether UOE might be more appropriate for 
implementations that do not support the XXX_PERSISTENT modes.

-Alan.

From Alan.Bateman at oracle.com  Mon Sep 10 18:06:12 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 19:06:12 +0100
Subject: Review Request: JDK-8210502: jdeps does not handle properly on
 analyzing a mixture of MR JARs and non-MR JARs
In-Reply-To: <413f5a60-cb43-05c8-aa18-cd85a0161536@oracle.com>
References: <413f5a60-cb43-05c8-aa18-cd85a0161536@oracle.com>
Message-ID: <ecd60fe6-f467-53e6-c8ba-7c1f19644dc9@oracle.com>



On 10/09/2018 18:53, mandy chung wrote:
> To analyze class dependencies of a multi-release JAR file,
> jdeps --multi-release option must be specified so that only
> entries of the specified version will be analyzed.
>
> This is to fix a bug in jdeps that fails when it is given
> both MR JARs and non-MR JARs.? --multi-release option should
> be accepted for non-MR JAR files and all unversioned entries
> will be analyzed.? The fix is trivial; just remove the check.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210502/webrev.00
Looks good.

-Alan

From aph at redhat.com  Mon Sep 10 18:15:24 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 10 Sep 2018 19:15:24 +0100
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <799fd248-17c0-d10b-f266-871cd5e8613f@linux.vnet.ibm.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <2cd3b913-0360-a674-b0f6-1153b224fb24@redhat.com>
 <b973dbaa4711387feafefcbeb4e0c9d478f3966a.camel@redhat.com>
 <799fd248-17c0-d10b-f266-871cd5e8613f@linux.vnet.ibm.com>
Message-ID: <2460415b-8efc-49af-c5fc-c1af4eff40d3@redhat.com>

On 09/10/2018 02:15 PM, Gustavo Romero wrote:
> Hi Severin,
> 
> On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
>> On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
>>> On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
>>>> Is there a good
>>>> reason to not use -O3 -ffp-contract=off everywhere?
>>>
>>> Is there a good reason to use -O3 rather than -O2?
>>
>> Not sure. I was following what JDK-8170153 did, which was using
>> OPTIMIZATION := HIGH corresponding to -O3. cc'ing Gustavo. Gustavo,
>> would you know why HIGH was chosen over, LOW?
> 
> I don't remember exactly, but at least for ppc64 I discussed that a bit with
> the toolchain folks (also regarding the precision issue, etc) and they never
> said anything against using -O3. Unfortunately it was long time ago so I
> don't remember exactly the numbers on ppc64 for -O2 to check if it was
> worse and so I selected -O3 instead.
> 
>>> -O3 can bloat the
>>> code which can increase cache pressure, which is not always noticeable
>>> in benchmarks but hurts real-world programs. Unless benchmarks are
>>> significantly better at -O3, -O2 is a good default choice.
>>
>> OK, thanks! I'll re-test and change to LOW (-O2) if it gives similar
>> results.
> 
> That's interesting. Andrew, do you mean bloat in the sense of final code size
> (for instance, due to unrolling), right?

Yes. With one of my other hats on: I'm also am occasional GCC
maintainer, and we've always had the problem that people assume that
O3 > O2, therefore O3 is better. It can be, but inlining can cause
problems due to code size and high register pressure, so it's good to
check. Let's see.

> BTW (I just remembered that), on RISC the lack of optimization hurts way more
> than the lack of optimization on CISC,

Mmm, yes. Inlining is cool if you have a ton of registers, and can
cause frantic spilling if you don't.

> so I recall that it puzzled me the fact that turning on the
> optimization on x86_64 did not change much the scenario, contrary to
> the conspicuous gains on on ppc64 when turning on the optimization.
> I took me some time so to understand that the optimization flag was
> the culprit (a much simpler case lucky), because I tried first to
> profile and optimize the fdlibm code (after extracting it from JVM
> for detailed analysis) and only after getting to a dead end I turned
> to look at simpler causes.
> 
> Are you checking the difference between -O2 and -O3 only on x86_64?

x86_64 has hand-carved code for a lot of this stuff, so it might not
much be affected.

-- 
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 Roger.Riggs at Oracle.com  Mon Sep 10 18:16:32 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Sep 2018 14:16:32 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
Message-ID: <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>

Please review the API and implementation of an API to parse Path strings.
Two methods are added to java.nio.file.Paths to parse a string using the 
path separator delimiter
and return either List<String> or List<Path>.? Empty path elements are 
ignored.

For compatibility with current URLClassPath behavior the internal 
implementation handles
replacement of empty paths.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/

CSR:
 ? https://bugs.openjdk.java.net/browse/JDK-8208208

Thanks, Roger


From jonathan.gibbons at oracle.com  Mon Sep 10 18:28:07 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 10 Sep 2018 11:28:07 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
Message-ID: <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>

Roger,

You've run into the standard naming ambiguity problem of "when is a path 
a search path, with elements separated by File.pathSeparator (e.g. class 
path, source path), and when is it a file path, with elements separated 
by File.separator (e.g. a nio.file.Path identifying a file or directory)?"

This shows up most obviously in the method confusingly named "pathToPaths".

In other contexts (javac, jtreg, etc) I've tried to use the term "search 
path" to describe the string that is a sequence of elements separated by 
File.pathSeparator.

-- Jon

On 9/10/18 11:16 AM, Roger Riggs wrote:
> Please review the API and implementation of an API to parse Path strings.
> Two methods are added to java.nio.file.Paths to parse a string using 
> the path separator delimiter
> and return either List<String> or List<Path>.? Empty path elements are 
> ignored.
>
> For compatibility with current URLClassPath behavior the internal 
> implementation handles
> replacement of empty paths.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>
>
> CSR:
> ? https://bugs.openjdk.java.net/browse/JDK-8208208
>
> Thanks, Roger
>


From calvin.cheung at oracle.com  Mon Sep 10 18:42:11 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 10 Sep 2018 11:42:11 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize() function
 to handle long path on windows
Message-ID: <5B96BB03.3070503@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8190737

webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/

Please review this change for handling long path specified in the 
-Xbootclasspath/a on windows.

Highlight of changes:
- canonicalize_md.c
     it makes use of the unicode version of canonicalize (wcanonicalize) 
if the original path is >= MAX_PATH.

- zip_util.c
     it uses the unicode version of CreateFile (CreateFileW) if the 
original path is >= MAX_PATH.

- io_util_md.c
     Since zip_util.c (libzip) calls the getPrefixed() function in 
canonicalize_md.c (libjava), the getPrefixed() function needs to be 
exported.

- java_md.h
     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It is 
because the the current usage of the canonicalize() function from vm 
code is to preallocate the output buffer as follows:
             char* canonical_path = NEW_RESOURCE_ARRAY_IN_THREAD(thread, 
char, JVM_MAXPATHLEN);
             if (!get_canonical_path(path, canonical_path, 
JVM_MAXPATHLEN)) {
     Also the unix version of canonicalize() function has the following 
check:
             int
            canonicalize(char *original, char *resolved, int len)
            {
                if (len < PATH_MAX) {
                errno = EINVAL;
                return -1;
            }
    So dynamically allocating the output buffer requires more work 
beyond the scope of this change.

- LongBCP.java
     added a scenario to the test - a long path to a jar file in 
-Xbootclasspath/a.

Testing: tier-[1,2,3].

thanks,
Calvin

From christoph.langer at sap.com  Mon Sep 10 19:29:42 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 10 Sep 2018 19:29:42 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
Message-ID: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>

Hi,

> > do you think we need property jdk.includeInExceptions=jar<File/Path> at
> all, if we don't resolve the absolute path?
> 
> I think so. File path is still sensitive.
> 
> In fact, I tend to believe people usually use absolute paths for JAR files (or
> maybe made absolute by using a file:// URL somewhere inside JDK). Do you
> really see relative jar paths while testing this code change?

I agree.

> > small remark to the code:
> > src/java.base/share/classes/sun/security/util/SecurityProperties.java
> > 36     public static String privilegeGetOverridable(String propName) {
> >
> > Should that method really be public? At the moment it doesn't seem to be
> used outside of SecurityProperties.
> 
> I like it to be public. There are quite some other such system/security
> properties (Ex: jdk.serialFilter) that can make use of this method.

Ok, maybe it should be named "priviledgedGetOverridable" then.

@Matthias:
Further small cleanups, as you touch the files:
src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can remove "import java.util.Iterator;"

src/java.base/share/classes/sun/net/util/SocketExceptions.java:
line 41: indentation is ridiculously long, I think it should be 8 chars

src/java.base/share/classes/sun/security/util/SecurityProperties.java:
Indentation of lines 38-45 is too deep, should be 12.
The 2 methods could use a brief Javadoc.

Best regards
Christoph

From Alan.Bateman at oracle.com  Mon Sep 10 19:41:46 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Sep 2018 20:41:46 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
Message-ID: <077df391-e27c-bf8c-416a-2b144d6113e7@oracle.com>



On 10/09/2018 19:28, Jonathan Gibbons wrote:
> Roger,
>
> You've run into the standard naming ambiguity problem of "when is a 
> path a search path, with elements separated by File.pathSeparator 
> (e.g. class path, source path), and when is it a file path, with 
> elements separated by File.separator (e.g. a nio.file.Path identifying 
> a file or directory)?"
>
> This shows up most obviously in the method confusingly named 
> "pathToPaths".
>
> In other contexts (javac, jtreg, etc) I've tried to use the term 
> "search path" to describe the string that is a sequence of elements 
> separated by File.pathSeparator.
I agree the naming is confusing as this API is about parsing a search 
path into its components. The Instrumentation API is another example 
where "Search" was put into the method name.

-Alan

From Roger.Riggs at Oracle.com  Mon Sep 10 20:34:43 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Sep 2018 16:34:43 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
Message-ID: <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>

Hi Jon, Alan,

No surprise and suggestions welcome!? :)

Since we don't have return type overloads, the name has to encode the 
return type (or the important aspects of it).
Is the search path the input string or the return value?? Well its both, 
but with different structure.

Remove the ambiguity:

  * a) Drop one of the APIs, leaving only the return of List<String> and
    push the conversion to Path to the consumer.
    e.g. List<Path> files = toSearchPath(String).stream().map(s ->
    Paths.of(s)).collect(Collectors.toList());
  * b) Drop the other API, always doing the conversion to Path and
    throwing exceptions.
    e.g. List<Path> toSearchPath(String);
    The Caller can get the string or file by calling toString() or
    toFile(); potentially wasting the effort to check the path syntax.

Disambiguate:

  * List<String> searchpathToStrings(s); List<Path> searchpathToPaths(s); or
    var files = Paths.searchpathToStrings("a;b;c");
    var searchpath = Paths.searchpathToPaths("x;y;z");
  * List<Path> toPathList(String searchpath); List<String>
    toStringList(String searchpath)
    Without static imports looks like:
    var files = Paths.toStringList("a;b;c").stream()....
    var searchpath = Paths.toPathList("x;y;z");
  * ???

Thanks, Roger

On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
> Roger,
>
> You've run into the standard naming ambiguity problem of "when is a 
> path a search path, with elements separated by File.pathSeparator 
> (e.g. class path, source path), and when is it a file path, with 
> elements separated by File.separator (e.g. a nio.file.Path identifying 
> a file or directory)?"
>
> This shows up most obviously in the method confusingly named 
> "pathToPaths".
>
> In other contexts (javac, jtreg, etc) I've tried to use the term 
> "search path" to describe the string that is a sequence of elements 
> separated by File.pathSeparator.
>
> -- Jon
>
> On 9/10/18 11:16 AM, Roger Riggs wrote:
>> Please review the API and implementation of an API to parse Path 
>> strings.
>> Two methods are added to java.nio.file.Paths to parse a string using 
>> the path separator delimiter
>> and return either List<String> or List<Path>.? Empty path elements 
>> are ignored.
>>
>> For compatibility with current URLClassPath behavior the internal 
>> implementation handles
>> replacement of empty paths.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>
>>
>> CSR:
>> ? https://bugs.openjdk.java.net/browse/JDK-8208208
>>
>> Thanks, Roger
>>
>


From jonathan.gibbons at oracle.com  Mon Sep 10 20:47:23 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 10 Sep 2018 13:47:23 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
Message-ID: <5B96D85B.9000807@oracle.com>

Roger,

I had in mind your first "disambiguate" suggetion (searchPathToStrings, 
searchPathToPaths)
but I note your  initial comment "Is the search path the input string or 
the return value?  Well its both, but with different structure. "

Since we have
     Paths.get

how about
     List<Path> Paths.getList(String searchPath)

I'd be less inclined to give formal support to converting to a 
List<String>. Those folk that want that could/should
be using String.split(File.pathSeparator) or something like that.

-- Jon

On 09/10/2018 01:34 PM, Roger Riggs wrote:
> Hi Jon, Alan,
>
> No surprise and suggestions welcome!  :)
>
> Since we don't have return type overloads, the name has to encode the 
> return type (or the important aspects of it).
> Is the search path the input string or the return value?  Well its 
> both, but with different structure.
>
> Remove the ambiguity:
>
>  * a) Drop one of the APIs, leaving only the return of List<String> and
>    push the conversion to Path to the consumer.
>    e.g. List<Path> files = toSearchPath(String).stream().map(s ->
>    Paths.of(s)).collect(Collectors.toList());
>  * b) Drop the other API, always doing the conversion to Path and
>    throwing exceptions.
>    e.g. List<Path> toSearchPath(String);
>    The Caller can get the string or file by calling toString() or
>    toFile(); potentially wasting the effort to check the path syntax.
>
> Disambiguate:
>
>  * List<String> searchpathToStrings(s); List<Path> 
> searchpathToPaths(s); or
>    var files = Paths.searchpathToStrings("a;b;c");
>    var searchpath = Paths.searchpathToPaths("x;y;z");
>  * List<Path> toPathList(String searchpath); List<String>
>    toStringList(String searchpath)
>    Without static imports looks like:
>    var files = Paths.toStringList("a;b;c").stream()....
>    var searchpath = Paths.toPathList("x;y;z");
>  * ???
>
> Thanks, Roger
>
> On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
>> Roger,
>>
>> You've run into the standard naming ambiguity problem of "when is a 
>> path a search path, with elements separated by File.pathSeparator 
>> (e.g. class path, source path), and when is it a file path, with 
>> elements separated by File.separator (e.g. a nio.file.Path 
>> identifying a file or directory)?"
>>
>> This shows up most obviously in the method confusingly named 
>> "pathToPaths".
>>
>> In other contexts (javac, jtreg, etc) I've tried to use the term 
>> "search path" to describe the string that is a sequence of elements 
>> separated by File.pathSeparator.
>>
>> -- Jon
>>
>> On 9/10/18 11:16 AM, Roger Riggs wrote:
>>> Please review the API and implementation of an API to parse Path 
>>> strings.
>>> Two methods are added to java.nio.file.Paths to parse a string using 
>>> the path separator delimiter
>>> and return either List<String> or List<Path>. Empty path elements 
>>> are ignored.
>>>
>>> For compatibility with current URLClassPath behavior the internal 
>>> implementation handles
>>> replacement of empty paths.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>>
>>>
>>> CSR:
>>>   https://bugs.openjdk.java.net/browse/JDK-8208208
>>>
>>> Thanks, Roger
>>>
>>
>


From Roger.Riggs at Oracle.com  Mon Sep 10 20:55:10 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Sep 2018 16:55:10 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <5B96D85B.9000807@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
Message-ID: <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>

Hi Jon,

On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
> Roger,
>
> I had in mind your first "disambiguate" suggetion 
> (searchPathToStrings, searchPathToPaths)
> but I note your? initial comment "Is the search path the input string 
> or the return value?? Well its both, but with different structure. "
>
> Since we have
> ??? Paths.get
>
> how about
> ??? List<Path> Paths.getList(String searchPath)
Not bad, but...

Perhaps, List<String> Paths.getListAsStrings(String searchPath)...
>
> I'd be less inclined to give formal support to converting to a 
> List<String>. Those folk that want that could/should
> be using String.split(File.pathSeparator) or something like that.
Nope!? there's quoting on Windows that gets short changed with that work 
around.

Other opinions?, Suggestions?

Thanks, Roger

>
> -- Jon
>
> On 09/10/2018 01:34 PM, Roger Riggs wrote:
>> Hi Jon, Alan,
>>
>> No surprise and suggestions welcome!? :)
>>
>> Since we don't have return type overloads, the name has to encode the 
>> return type (or the important aspects of it).
>> Is the search path the input string or the return value?? Well its 
>> both, but with different structure.
>>
>> Remove the ambiguity:
>>
>> ?* a) Drop one of the APIs, leaving only the return of List<String> and
>> ?? push the conversion to Path to the consumer.
>> ?? e.g. List<Path> files = toSearchPath(String).stream().map(s ->
>> ?? Paths.of(s)).collect(Collectors.toList());
>> ?* b) Drop the other API, always doing the conversion to Path and
>> ?? throwing exceptions.
>> ?? e.g. List<Path> toSearchPath(String);
>> ?? The Caller can get the string or file by calling toString() or
>> ?? toFile(); potentially wasting the effort to check the path syntax.
>>
>> Disambiguate:
>>
>> ?* List<String> searchpathToStrings(s); List<Path> 
>> searchpathToPaths(s); or
>> ?? var files = Paths.searchpathToStrings("a;b;c");
>> ?? var searchpath = Paths.searchpathToPaths("x;y;z");
>> ?* List<Path> toPathList(String searchpath); List<String>
>> ?? toStringList(String searchpath)
>> ?? Without static imports looks like:
>> ?? var files = Paths.toStringList("a;b;c").stream()....
>> ?? var searchpath = Paths.toPathList("x;y;z");
>> ?* ???
>>
>> Thanks, Roger
>>
>> On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
>>> Roger,
>>>
>>> You've run into the standard naming ambiguity problem of "when is a 
>>> path a search path, with elements separated by File.pathSeparator 
>>> (e.g. class path, source path), and when is it a file path, with 
>>> elements separated by File.separator (e.g. a nio.file.Path 
>>> identifying a file or directory)?"
>>>
>>> This shows up most obviously in the method confusingly named 
>>> "pathToPaths".
>>>
>>> In other contexts (javac, jtreg, etc) I've tried to use the term 
>>> "search path" to describe the string that is a sequence of elements 
>>> separated by File.pathSeparator.
>>>
>>> -- Jon
>>>
>>> On 9/10/18 11:16 AM, Roger Riggs wrote:
>>>> Please review the API and implementation of an API to parse Path 
>>>> strings.
>>>> Two methods are added to java.nio.file.Paths to parse a string 
>>>> using the path separator delimiter
>>>> and return either List<String> or List<Path>. Empty path elements 
>>>> are ignored.
>>>>
>>>> For compatibility with current URLClassPath behavior the internal 
>>>> implementation handles
>>>> replacement of empty paths.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>>>
>>>>
>>>> CSR:
>>>> ? https://bugs.openjdk.java.net/browse/JDK-8208208
>>>>
>>>> Thanks, Roger
>>>>
>>>
>>
>


From jonathan.gibbons at oracle.com  Mon Sep 10 21:06:17 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 10 Sep 2018 14:06:17 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
Message-ID: <5B96DCC9.6070300@oracle.com>

OK, I understand the need for quoting, although I wonder how many folk 
have bothered with that up to now (looking at javac, jtreg!) ;-)

I'd stay with

     List<Path> getList(String searchPath)

and then either have people use

getList(searchPath).stream().map(Path::toString).collect(Collectors.toList())

or if we want the extra method, then

     List<String> getListAsStrings(String searchPath)

-- Jon


On 09/10/2018 01:55 PM, Roger Riggs wrote:
> Hi Jon,
>
> On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
>> Roger,
>>
>> I had in mind your first "disambiguate" suggetion 
>> (searchPathToStrings, searchPathToPaths)
>> but I note your  initial comment "Is the search path the input string 
>> or the return value?  Well its both, but with different structure. "
>>
>> Since we have
>>     Paths.get
>>
>> how about
>>     List<Path> Paths.getList(String searchPath)
> Not bad, but...
>
> Perhaps, List<String> Paths.getListAsStrings(String searchPath)...
>>
>> I'd be less inclined to give formal support to converting to a 
>> List<String>. Those folk that want that could/should
>> be using String.split(File.pathSeparator) or something like that.
> Nope!  there's quoting on Windows that gets short changed with that 
> work around.
>
> Other opinions?, Suggestions?
>
> Thanks, Roger
>
>>
>> -- Jon
>>
>> On 09/10/2018 01:34 PM, Roger Riggs wrote:
>>> Hi Jon, Alan,
>>>
>>> No surprise and suggestions welcome!  :)
>>>
>>> Since we don't have return type overloads, the name has to encode 
>>> the return type (or the important aspects of it).
>>> Is the search path the input string or the return value?  Well its 
>>> both, but with different structure.
>>>
>>> Remove the ambiguity:
>>>
>>>  * a) Drop one of the APIs, leaving only the return of List<String> and
>>>    push the conversion to Path to the consumer.
>>>    e.g. List<Path> files = toSearchPath(String).stream().map(s ->
>>>    Paths.of(s)).collect(Collectors.toList());
>>>  * b) Drop the other API, always doing the conversion to Path and
>>>    throwing exceptions.
>>>    e.g. List<Path> toSearchPath(String);
>>>    The Caller can get the string or file by calling toString() or
>>>    toFile(); potentially wasting the effort to check the path syntax.
>>>
>>> Disambiguate:
>>>
>>>  * List<String> searchpathToStrings(s); List<Path> 
>>> searchpathToPaths(s); or
>>>    var files = Paths.searchpathToStrings("a;b;c");
>>>    var searchpath = Paths.searchpathToPaths("x;y;z");
>>>  * List<Path> toPathList(String searchpath); List<String>
>>>    toStringList(String searchpath)
>>>    Without static imports looks like:
>>>    var files = Paths.toStringList("a;b;c").stream()....
>>>    var searchpath = Paths.toPathList("x;y;z");
>>>  * ???
>>>
>>> Thanks, Roger
>>>
>>> On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
>>>> Roger,
>>>>
>>>> You've run into the standard naming ambiguity problem of "when is a 
>>>> path a search path, with elements separated by File.pathSeparator 
>>>> (e.g. class path, source path), and when is it a file path, with 
>>>> elements separated by File.separator (e.g. a nio.file.Path 
>>>> identifying a file or directory)?"
>>>>
>>>> This shows up most obviously in the method confusingly named 
>>>> "pathToPaths".
>>>>
>>>> In other contexts (javac, jtreg, etc) I've tried to use the term 
>>>> "search path" to describe the string that is a sequence of elements 
>>>> separated by File.pathSeparator.
>>>>
>>>> -- Jon
>>>>
>>>> On 9/10/18 11:16 AM, Roger Riggs wrote:
>>>>> Please review the API and implementation of an API to parse Path 
>>>>> strings.
>>>>> Two methods are added to java.nio.file.Paths to parse a string 
>>>>> using the path separator delimiter
>>>>> and return either List<String> or List<Path>. Empty path elements 
>>>>> are ignored.
>>>>>
>>>>> For compatibility with current URLClassPath behavior the internal 
>>>>> implementation handles
>>>>> replacement of empty paths.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>>>>
>>>>>
>>>>> CSR:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8208208
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Sep 10 21:34:41 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Sep 2018 14:34:41 -0700
Subject: [12]: RFR: Use CLDR's time zone mappings for Windows
Message-ID: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8209167/webrev.01/

This fix is to remove the hand crafted map file (lib/tzmappings) on 
Windows, which maps Windows time zones to Java's tzid. It is now 
dynamically generated at the build time, using CLDR's data file 
(windowsZones.xml)

Naoto

From erik.joelsson at oracle.com  Mon Sep 10 21:43:15 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Sep 2018 14:43:15 -0700
Subject: [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
Message-ID: <f08f18d0-1920-10d7-8819-9a60898439b4@oracle.com>

Looks good.

/Erik


On 2018-09-10 14:34, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209167
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>
> This fix is to remove the hand crafted map file (lib/tzmappings) on 
> Windows, which maps Windows time zones to Java's tzid. It is now 
> dynamically generated at the build time, using CLDR's data file 
> (windowsZones.xml)
>
> Naoto


From xueming.shen at oracle.com  Tue Sep 11 00:05:14 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 10 Sep 2018 17:05:14 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize() function
 to handle long path on windows
In-Reply-To: <5B96BB03.3070503@oracle.com>
References: <5B96BB03.3070503@oracle.com>
Message-ID: <5B9706BA.4080409@oracle.com>

On 9/10/18, 11:42 AM, Calvin Cheung wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>
> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>
> Please review this change for handling long path specified in the 
> -Xbootclasspath/a on windows.
>
> Highlight of changes:
> - canonicalize_md.c
>     it makes use of the unicode version of canonicalize 
> (wcanonicalize) if the original path is >= MAX_PATH.
So we are converting mb->wc->mb in wcanonicalize (when > max_path), and 
then feed the
resulting path into ZFILE_Open, in which we again do mb->wc-> + prefix 
-> CreateFileW(...)?

Maybe it's time to consider a "wchar" interface between vm and 
libraries. Maybe it's fine here given we
are only do this for > max_path case?

Alan, now reading the win version canonicalize(...), remind me what's 
the real purpose of doing
FindFirstFile/FindClose() here? the API appears to suggest it is used to 
find the first match if there
is/are wildcards but we actually have checked/rejected the wildcards at 
the very beginning ? To
get the "real name" for case?

>
> - zip_util.c
>     it uses the unicode version of CreateFile (CreateFileW) if the 
> original path is >= MAX_PATH.
>
> - io_util_md.c
>     Since zip_util.c (libzip) calls the getPrefixed() function in 
> canonicalize_md.c (libjava), the getPrefixed() function needs to be 
> exported.

I kinda remembered that we once wanted to avoid export an variant of 
winFileHandleOpen() from
libjava to libzip ... in this case the alternative is to simply 
copy/paste the getPrefix into libzip ...
but I don't remember the exact concern back then.

-Sherman



>
>
> - java_md.h
>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It 
> is because the the current usage of the canonicalize() function from 
> vm code is to preallocate the output buffer as follows:
>             char* canonical_path = 
> NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>             if (!get_canonical_path(path, canonical_path, 
> JVM_MAXPATHLEN)) {
>     Also the unix version of canonicalize() function has the following 
> check:
>             int
>            canonicalize(char *original, char *resolved, int len)
>            {
>                if (len < PATH_MAX) {
>                errno = EINVAL;
>                return -1;
>            }
>    So dynamically allocating the output buffer requires more work 
> beyond the scope of this change.
>
> - LongBCP.java
>     added a scenario to the test - a long path to a jar file in 
> -Xbootclasspath/a.
>
> Testing: tier-[1,2,3].
>
> thanks,
> Calvin


From weijun.wang at oracle.com  Tue Sep 11 00:13:38 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Sep 2018 08:13:38 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
Message-ID: <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com>



> On Sep 11, 2018, at 3:29 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Ok, maybe it should be named "priviledgedGetOverridable" then.

Ah yes. My mistake.

From xu.y.yin at oracle.com  Tue Sep 11 00:54:57 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Tue, 11 Sep 2018 08:54:57 +0800
Subject: [12] RFR 8209773: Refactor shell test
 javax/naming/module/basic.sh to java
In-Reply-To: <ab3c691b-5426-4321-4631-f8ff61c00571@oracle.com>
References: <2FD3C587-564D-4A49-BB8F-6EBC94C2A499@oracle.com>
 <0a6bfde2-64d4-f66b-a850-70be32ead0b1@oracle.com>
 <fbb31c4c-c7f1-a837-d485-cd834d5f6917@oracle.com>
 <E6F12533-7262-482B-8AE7-550C8F8D5A70@oracle.com>
 <ab3c691b-5426-4321-4631-f8ff61c00571@oracle.com>
Message-ID: <780A43AE-0B35-44E7-A60D-72783A6A5EF5@oracle.com>

Thank you, Alan

Regards,
Chris

> On 10 Sep 2018, at 5:42 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 10/09/2018 10:13, Chris Yin wrote:
>> Thank you, Alan
>> 
>> Sure, I modified a little to remove ?.? and use Path.of as you suggested to improve file handling, minor revision as below, thanks
>> 
>> http://cr.openjdk.java.net/~xyin/8209773/webrev.01/
>> 
>> 
> The update looks okay to me.
> 
> -Alan


From orionllmain at gmail.com  Tue Sep 11 01:42:09 2018
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Tue, 11 Sep 2018 08:42:09 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAD4YxQU_P76AV2BEg0GQdYxz2Xk42SnnCK0GB+KZoEAnz6MRXQ@mail.gmail.com>
References: <CAD4YxQU_P76AV2BEg0GQdYxz2Xk42SnnCK0GB+KZoEAnz6MRXQ@mail.gmail.com>
Message-ID: <CAF2POUewi8n7RDXpJHqMo+fOv9gzSGi34N1f90TJPBB86-FG_w@mail.gmail.com>

public static <T, A, R, RR> Collector<T, A, RR> collectingAndThen(
                                 Collector<T, A, R> downstream,
                                 Function<R, RR> finisher);

public static <T, R1, R2, R> Collector<T, ?, R> collectingAndThen(
                                 Collector<? super T, ?, R1> downstream1,
                                 Collector<? super T, ?, R2> downstream2,
                                 BiFunction<? super R1, ? super R2, ?
extends R> finisher);


??, 8 ????. 2018 ?. ? 20:00, Tomasz Linkowski <t.linkowski at gmail.com>:

> Hello,
>
> I'm responding to the thread at [1] (I'm not sure whether my message will
> get appended to it) and the CSR at [2].
>
> I stumbled here from StackOverflow where - indepedently of all the others -
> I also came up with this type of "dual" *Collector* [3]. I named it
> "collectingBoth" there but I'd like to suggest a slightly different name
> here.
>
> I believe that Zheka Kozlov made a great observation about similiarity to
> "collectingAndThen" [4]. And it seems Brian Goetz favors the "AndThen"
> suffix [5]. On the other hand, this new Collector differs from
> "collectingAndThen" in that:
> 1) it hides the accumulation type parameters (A1, A2), and
> 2) it needs a few lower bounds on some of its type parameters.
>
> All in all, I'd like to propose to name the method "collectingBothAndThen"
> (or alternatively: "biCollectingAndThen".
>
> As an aside, I'd like to suggest changing the name of the parameter from
> "merger" to "biFinisher":
> 1) Peter Levart pointed out in [6] that "finisher" is already taken by the
> Collector API (and it's true), but it didn't prevent "collectingAndThen"
> from taking a "finisher" and then
> calling: downstream.finisher().andThen(finisher)
> 2) note that in all other contexts "merger" represents a BinaryOperator
> because it merges two values of the *same* type, and here the types of
> merged values are different.
>
> Complete signatures for comparison below:
>
> *<T,A,R,RR> Collector<T,A,RR> collectingAndThen(*
> *    Collector<T, A, R> downstream,*
> *    Function<R, RR> finisher)*
>
> *<T,R1,R2,R> Collector<T,?,R> collectingBothAndThen(*
> *    Collector<? super T, ?, R1> downstream1,*
> *    Collector<? super T, ?, R2> downstream2,*
> *    BiFunction<? super R1, ? super R2, R> biFinisher)*
>
>
> As to the other potential names, I must say:
> - I'm not in favor of "teeingAndThen" nor all the duplex-related names (I
> find them unintuitive, especially the "teeing" one),
> - I really like "composite" and "compound" proposed by Stuart Marks [7]; it
> seems that "compouding" could be both intuitive and adhering to the -ing
> suffix convention
>
> [1]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054718.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8209685
> [3] https://stackoverflow.com/a/52211175/2032415
> [4]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053922.html
> [5]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054736.html
> [6]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054724.html
> [7]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html
>
> --
> Regards,
> Tomasz Linkowski
>

From stuart.marks at oracle.com  Tue Sep 11 02:24:26 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Sep 2018 19:24:26 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
Message-ID: <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>

Hi Jaikiran,

Terribly sorry about this. I completely missed the review request you posted on 
this a couple weeks ago now.

Comments below.

> Returns a fixed-size list backed by the specified array.

OK. Same as the original. :-)

> The passed array is held as a reference in the returned list.

While this is true, this is really a statement about implementation. For the 
specification, we want to focus on assertions about the behavior. Please remove.

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

This is an improvement on the original "(Changes to the returned list "write 
through" to the array)" which doesn't describe the behavior precisely enough nor 
does it discuss the "bi-directional" nature of visibility of the changes. The 
proposed text is a bit verbose, however; I'd suggest the following:

     Changes made to the array will be visible in the returned list, and
     changes made to the list will be visible in the array.

> The returned list is serializable and implements {@link RandomAccess}.

(This was from the original text.) It's kind of odd that RandomAccess is a link 
but Serializable is not. I'd suggest making Serializable a link as follows:

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

This text would be fine for something like a tutorial, but it's not precise 
enough in that it describes behavior by example ("operations like...") and it 
doesn't specify the behavior if a disallowed operation is performed. I'd suggest 
this instead:

     Operations that would change the size of the returned list leave the
     list unchanged and throw {@link UnsupportedOperationException}.

Listing the exact methods that can change the size is unwise, as it can change 
over time and the list will become out of date. There are also a lot of obscure 
ways to change the size of a list besides methods on the list, e.g. via an 
iterator's remove(), a sublist's size-change method, removeIf(), etc. and it's 
not worth trying to chase them all down.

> This method acts as bridge between array-based and collection-based APIs, in
> combination with {@link Collection#toArray}.

This (from the original text) should actually be part of the @apiNote. However, 
it was written before the @apiNote concept existed. So, start the @apiNote 
before this text.

> 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.
This UOE statement now redundant with the above.

The latter statement is unfortunately true; the various collections 
implementations aren't consistent as to whether they will fail if a disallowed 
method is called or whether such a call would actually modify the list. For 
example, appending an empty list to a Collections.unmodifiableList() will throw 
UOE, but this is a no-op for a Collections.singletonList(). Note however that 
there is only one implementation of Arrays.asList() so the "certain 
implementations" discussion is misplaced. There's already some discussion of 
this issue in the Collection class doc, so this isn't needed here.

I do think it's reasonable to have examples here. Interestingly, the original 
(pre-varargs) purpose of Arrays.asList() was to wrap an existing array in a 
list. With varargs, this method is probably now more often used to create a list 
from arguments. Both uses are valid, but the first is now less obvious and so I 
think deserves a new example. The latter remains valid even with List.of() and 
friends, since those methods make a copy of the array that might not be 
necessary in all cases.

Here's what I'd suggest:

  - add a simple (~2 line) example showing wrapping of an existing array
    in a list

  - restore the "Three Stooges" example (beginning with "This method also 
provides...")

  - add a note emphasizing that the returned list is NOT unmodifiable. it's a 
common mistake to assume that it is. I'd also put in a reference to 
List.html#unmodifiable here in case people do want an unmodifiable list.

>      * @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
>      * @see List#of()

OK. We probably don't need the @see for List.of if there's a reference to the 
"unmodifiable lists" section above.

**

I can sponsor this change for you. Since we're changing testable assertions, 
this will also require a CSR request. I'll take care of that for you too.

Thanks,

s'marks







On 9/10/18 12:31 AM, Jaikiran Pai wrote:
> Any other reviews? I'm not a committer, so I'll also need someone to
> help sponsor this patch.
> 
> -Jaikiran
> 
> 
> On 06/09/18 7:39 PM, Jaikiran Pai wrote:
>> On 06/09/18 1:24 PM, Bernd Eckenfels wrote:
>>> Yes you are right @apinote is aproperiate section (was confusing it with implnote).
>>>
>>> Still think a ?literal specified list? is no longer a good (as in canonical) usecase for that method.
>>>
>>> I used it in the past often to get a List for using toString() on it, but I guess even for that case List.of can be used instead now.
>>>
>>> So @see List#of and let the reader figure out when to use them?
>> That sounds good to me. I've now updated it to reflect this change and
>> the javadoc now looks as below. I've also attached the new updated patch.
>>
>>  ??? /**
>>  ???? * 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
>>  ???? * 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
>>  ???? * @see List#of()
>>  ???? */
>>
>>
>>
>> -Jaikiran
>>
> 

From stuart.marks at oracle.com  Tue Sep 11 02:28:14 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Sep 2018 19:28:14 -0700
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <69b2a09539384016b890e64e71700809@sap.com>
 <c0ef82f0-ad52-f913-2fd1-99ddd853692a@oracle.com>
 <46322abe1477459cad6ea342950b2da4@sap.com>
 <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com>
Message-ID: <7619d4d5-ad06-f8d0-8da7-04f002763f7e@oracle.com>



On 9/10/18 5:13 PM, Weijun Wang wrote:
> 
> 
>> On Sep 11, 2018, at 3:29 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
>>
>> Ok, maybe it should be named "priviledgedGetOverridable" then.
> 
> Ah yes. My mistake.

Small spelling nit: there's no "d" before "g", so this should likely be

     privilegedGetOverridable

s'marks

From vyom.tewari at oracle.com  Tue Sep 11 08:50:57 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Tue, 11 Sep 2018 14:20:57 +0530
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <a481f947-637e-4576-176d-8f4b3767f6c2@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
 <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
 <a481f947-637e-4576-176d-8f4b3767f6c2@oracle.com>
Message-ID: <440cc12e-d6f1-3560-554f-1adae9a92ed5@oracle.com>

Hi Chris,Daniel,

Please find the latest patch( 
http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).

I did the additional cleanup(removed redundant null check) as you suggested.

Thanks,

Vyom


On Monday 10 September 2018 09:03 PM, Daniel Fuchs wrote:
> On 10/09/2018 15:53, vyom tewari wrote:
>> Yes , this will definitely solve this NPE issue but we may hit NPE 
>> other places as well because we are setting 'LdapClient.com' to null 
>> asynchronously.
>
> I agree with Vyom here.
>
> Other solutions that have been investigated - such as only
> setting the connection to null when its ref count reaches zero
> now seem to complex (read: too risky because over the complexity
> threshold) to me.
>
> Maybe the best thing to do here is to stick to Vyom original's
> idea, but declare conn final and do all the necessary (small)
> cleanup that goes with it? Possibly also add a comment saying
> that CommunicationException will be thrown if some other thread
> uses the LdapClient after forceClose has been closed...
>
> best regards,
>
> -- daniel
>


From matthias.baesken at sap.com  Tue Sep 11 09:07:25 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 11 Sep 2018 09:07:25 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
Message-ID: <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>

Hello, please check the new webrev  :

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/

I kept the jarPath   category name .

Best regards, Matthias


> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 10. September 2018 21:30
> To: Weijun Wang <weijun.wang at oracle.com>; Baesken, Matthias
> <matthias.baesken at sap.com>
> Cc: Sean Mullan <sean.mullan 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
> 
> Hi,
> 
> > > do you think we need property jdk.includeInExceptions=jar<File/Path> at
> > all, if we don't resolve the absolute path?
> >
> > I think so. File path is still sensitive.
> >
> > In fact, I tend to believe people usually use absolute paths for JAR files (or
> > maybe made absolute by using a file:// URL somewhere inside JDK). Do
> you
> > really see relative jar paths while testing this code change?
> 
> I agree.
> 
> > > small remark to the code:
> > > src/java.base/share/classes/sun/security/util/SecurityProperties.java
> > > 36     public static String privilegeGetOverridable(String propName) {
> > >
> > > Should that method really be public? At the moment it doesn't seem to
> be
> > used outside of SecurityProperties.
> >
> > I like it to be public. There are quite some other such system/security
> > properties (Ex: jdk.serialFilter) that can make use of this method.
> 
> Ok, maybe it should be named "priviledgedGetOverridable" then.
> 
> @Matthias:
> Further small cleanups, as you touch the files:
> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can
> remove "import java.util.Iterator;"
> 
> src/java.base/share/classes/sun/net/util/SocketExceptions.java:
> line 41: indentation is ridiculously long, I think it should be 8 chars
> 
> src/java.base/share/classes/sun/security/util/SecurityProperties.java:
> Indentation of lines 38-45 is too deep, should be 12.
> The 2 methods could use a brief Javadoc.
> 
> Best regards
> Christoph


From Alan.Bateman at oracle.com  Tue Sep 11 09:24:36 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Sep 2018 10:24:36 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
Message-ID: <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>

On 10/09/2018 21:55, Roger Riggs wrote:
> Nope! there's quoting on Windows that gets short changed with that 
> work around.
>
> Other opinions?, Suggestions?
One suggestion is reduce this down to one method that returns a stream 
rather than a collection. It could work lazily if you want. Something like:

 ? Stream<String> splitSearchPath(String input)

is a lot more flexible (in my view) and the places where we use Path 
objects can use .map(Path::of).

In passing, I see the current patch changes the UCP constructor that is 
used for supporting -Xbootclasspath/a. That that will to be checked to 
see if it has any impact on startup.

-Alan


From Alan.Bateman at oracle.com  Tue Sep 11 09:57:24 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Sep 2018 10:57:24 +0100
Subject: RFR(S) 8190737: use unicode version of the canonicalize()
 function to handle long path on windows
In-Reply-To: <5B9706BA.4080409@oracle.com>
References: <5B96BB03.3070503@oracle.com> <5B9706BA.4080409@oracle.com>
Message-ID: <4fce20bd-d40e-8f10-d05a-8ca3fad6be95@oracle.com>

On 11/09/2018 01:05, Xueming Shen wrote:
> :
>
> Alan, now reading the win version canonicalize(...), remind me what's 
> the real purpose of doing
> FindFirstFile/FindClose() here? the API appears to suggest it is used 
> to find the first match if there
> is/are wildcards but we actually have checked/rejected the wildcards 
> at the very beginning ? To
> get the "real name" for case?
Casing and maybe 8.3 vs. long names but would need to dig into it to 
double check.

-Alan

From weijun.wang at oracle.com  Tue Sep 11 11:03:33 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Sep 2018 19:03:33 +0800
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>

Attributes.java:

- Line 377: Too long, add a break.

Otherwise fine.

I don't have a strong opinion on making Manifest.jarFilename final or a different property name.

Thanks
Max

> On Sep 11, 2018, at 5:07 PM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello, please check the new webrev  :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/
> 
> I kept the jarPath   category name .
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Montag, 10. September 2018 21:30
>> To: Weijun Wang <weijun.wang at oracle.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>
>> Cc: Sean Mullan <sean.mullan 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
>> 
>> Hi,
>> 
>>>> do you think we need property jdk.includeInExceptions=jar<File/Path> at
>>> all, if we don't resolve the absolute path?
>>> 
>>> I think so. File path is still sensitive.
>>> 
>>> In fact, I tend to believe people usually use absolute paths for JAR files (or
>>> maybe made absolute by using a file:// URL somewhere inside JDK). Do
>> you
>>> really see relative jar paths while testing this code change?
>> 
>> I agree.
>> 
>>>> small remark to the code:
>>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java
>>>> 36     public static String privilegeGetOverridable(String propName) {
>>>> 
>>>> Should that method really be public? At the moment it doesn't seem to
>> be
>>> used outside of SecurityProperties.
>>> 
>>> I like it to be public. There are quite some other such system/security
>>> properties (Ex: jdk.serialFilter) that can make use of this method.
>> 
>> Ok, maybe it should be named "priviledgedGetOverridable" then.
>> 
>> @Matthias:
>> Further small cleanups, as you touch the files:
>> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can
>> remove "import java.util.Iterator;"
>> 
>> src/java.base/share/classes/sun/net/util/SocketExceptions.java:
>> line 41: indentation is ridiculously long, I think it should be 8 chars
>> 
>> src/java.base/share/classes/sun/security/util/SecurityProperties.java:
>> Indentation of lines 38-45 is too deep, should be 12.
>> The 2 methods could use a brief Javadoc.
>> 
>> Best regards
>> Christoph
> 


From chris.hegarty at oracle.com  Tue Sep 11 11:15:35 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 11 Sep 2018 12:15:35 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <440cc12e-d6f1-3560-554f-1adae9a92ed5@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
 <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
 <a481f947-637e-4576-176d-8f4b3767f6c2@oracle.com>
 <440cc12e-d6f1-3560-554f-1adae9a92ed5@oracle.com>
Message-ID: <C4AAF8EC-7736-4CC9-B610-8B6988138232@oracle.com>


> On 11 Sep 2018, at 09:50, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,Daniel,
> 
> Please find the latest patch( http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).

Thanks Vyom, Reviewed.

-Chris.

From matthias.baesken at sap.com  Tue Sep 11 11:29:12 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 11 Sep 2018 11:29:12 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
Message-ID: <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>

> I don't have a strong opinion on making Manifest.jarFilename final 

Hi, just making it final  leads to compile errors anyway.

Best regards, Matthias


> -----Original Message-----
> From: Weijun Wang <weijun.wang at oracle.com>
> Sent: Dienstag, 11. September 2018 13:04
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; Sean Mullan
> <sean.mullan 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
> 
> Attributes.java:
> 
> - Line 377: Too long, add a break.
> 
> Otherwise fine.
> 
> I don't have a strong opinion on making Manifest.jarFilename final or a
> different property name.
> 
> Thanks
> Max
> 
> > On Sep 11, 2018, at 5:07 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hello, please check the new webrev  :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/
> >
> > I kept the jarPath   category name .
> >
> > Best regards, Matthias
> >
> >
> >> -----Original Message-----
> >> From: Langer, Christoph
> >> Sent: Montag, 10. September 2018 21:30
> >> To: Weijun Wang <weijun.wang at oracle.com>; Baesken, Matthias
> >> <matthias.baesken at sap.com>
> >> Cc: Sean Mullan <sean.mullan 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
> >>
> >> Hi,
> >>
> >>>> do you think we need property jdk.includeInExceptions=jar<File/Path>
> at
> >>> all, if we don't resolve the absolute path?
> >>>
> >>> I think so. File path is still sensitive.
> >>>
> >>> In fact, I tend to believe people usually use absolute paths for JAR files
> (or
> >>> maybe made absolute by using a file:// URL somewhere inside JDK). Do
> >> you
> >>> really see relative jar paths while testing this code change?
> >>
> >> I agree.
> >>
> >>>> small remark to the code:
> >>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java
> >>>> 36     public static String privilegeGetOverridable(String propName) {
> >>>>
> >>>> Should that method really be public? At the moment it doesn't seem to
> >> be
> >>> used outside of SecurityProperties.
> >>>
> >>> I like it to be public. There are quite some other such system/security
> >>> properties (Ex: jdk.serialFilter) that can make use of this method.
> >>
> >> Ok, maybe it should be named "priviledgedGetOverridable" then.
> >>
> >> @Matthias:
> >> Further small cleanups, as you touch the files:
> >> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can
> >> remove "import java.util.Iterator;"
> >>
> >> src/java.base/share/classes/sun/net/util/SocketExceptions.java:
> >> line 41: indentation is ridiculously long, I think it should be 8 chars
> >>
> >> src/java.base/share/classes/sun/security/util/SecurityProperties.java:
> >> Indentation of lines 38-45 is too deep, should be 12.
> >> The 2 methods could use a brief Javadoc.
> >>
> >> Best regards
> >> Christoph
> >


From chris.hegarty at oracle.com  Tue Sep 11 11:50:49 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 11 Sep 2018 12:50:49 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
Message-ID: <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>


> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 10/09/2018 21:55, Roger Riggs wrote:
>> Nope! there's quoting on Windows that gets short changed with that work around.
>> 
>> Other opinions?, Suggestions?
> One suggestion is reduce this down to one method that returns a stream rather than a collection. It could work lazily if you want. Something like:
> 
>   Stream<String> splitSearchPath(String input)

I agree with Alan, this seems like the lowest-order primitive.

I refreshed my memory of search path splitting from the `jmod` tool,
where such an API would be useful ( if we weren?t using joptsimple ).
There are two separate use cases, ClassPathConverter, and
DirPathConverter ( in JmodTask ), both of which resolve each String
path value against the current working directory, and do some
context specific validation.

-Chris.



From daniel.fuchs at oracle.com  Tue Sep 11 11:53:00 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 11 Sep 2018 12:53:00 +0100
Subject: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the
 server has sent a disconnection
In-Reply-To: <C4AAF8EC-7736-4CC9-B610-8B6988138232@oracle.com>
References: <24b36946-7e9c-1213-225f-25b5dd7f433e@oracle.com>
 <0f924c21-f741-a8a3-76b0-d9ad16312c35@oracle.com>
 <229af019-ef37-9116-06bf-577ce3b8de95@oracle.com>
 <812da89f-f8c5-64cc-b49e-c10f2f4702c5@oracle.com>
 <633a13a9-6331-2d93-5662-e94b5f3c3434@oracle.com>
 <8e961aa3-d53c-40e9-0b91-6cf0d313eaa3@oracle.com>
 <ad91fa19-2e9e-002a-e238-58119926c5c0@oracle.com>
 <b0f99173-20a5-2772-7c27-c2bb256c7294@oracle.com>
 <a481f947-637e-4576-176d-8f4b3767f6c2@oracle.com>
 <440cc12e-d6f1-3560-554f-1adae9a92ed5@oracle.com>
 <C4AAF8EC-7736-4CC9-B610-8B6988138232@oracle.com>
Message-ID: <ae749e93-78ab-3735-aad0-b3c77f7d78f8@oracle.com>

On 11/09/2018 12:15, Chris Hegarty wrote:
> 
>> On 11 Sep 2018, at 09:50, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,Daniel,
>>
>> Please find the latest patch( http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ).
> 
> Thanks Vyom, Reviewed.

Agreed.

best regards,

-- daniel

> 
> -Chris.
> 


From sgehwolf at redhat.com  Tue Sep 11 12:02:21 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Sep 2018 14:02:21 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
Message-ID: <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>

On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> I see. I was not aware of that issue, but we clearly need to file a bug 
> for it and fix it. In this case I think it's fine to us the macro however.

OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/

Micro-benchmark results from running [1] for x86_64 and ppc64le are
here (-O2 is sufficient it seems):

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/

More thoughts?

Thanks,
Severin

[1] https://github.com/gromero/strictmath/


From christoph.langer at sap.com  Tue Sep 11 12:14:15 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 11 Sep 2018 12:14:15 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@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>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
 <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <bc465382ae334570878668cc2e5612d3@sap.com>

Hi,

first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there were further Exception details to be added in the area of jar files, they could go under a category "jarDetails" as well. Would you agree? Then, in Manifest.java, the field "jarPathInExceptionText" could be renamed to "detailedExceptions".

As for the code, I have the following remarks:

src/java.base/share/classes/java/util/jar/Manifest.java:
You could further clean up the ordering of includes by sorting them alphabetically and add a blank line between lines 34/35.
Line 52: I suggest an indentation of 8 chars
Please use jarFilename as final. You'll have to initialize jarFilename in each constructor then or initialize it to null in the default constructor and call this constructor from all the other ctors except for the one taking the jarFilename as param.

src/java.base/share/classes/sun/net/util/SocketExceptions.java
please add an empty line between 32 and 33
Line 39: I suggest an indentation of 8 chars

src/java.base/share/classes/sun/security/util/SecurityProperties.java
Line 35: change comment opener to /** (from /*), then it's a real Javadoc
Furthermore I suggest to change the wording to "Returns the value of the security property propName, which can be overridden by a system property of the same name"

Best regards
Christoph

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Dienstag, 11. September 2018 13:29
> To: Weijun Wang <weijun.wang at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; Sean Mullan
> <sean.mullan 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
> 
> > I don't have a strong opinion on making Manifest.jarFilename final
> 
> Hi, just making it final  leads to compile errors anyway.
> 
> Best regards, Matthias
> 
> 
> > -----Original Message-----
> > From: Weijun Wang <weijun.wang at oracle.com>
> > Sent: Dienstag, 11. September 2018 13:04
> > To: Baesken, Matthias <matthias.baesken at sap.com>
> > Cc: Langer, Christoph <christoph.langer at sap.com>; Sean Mullan
> > <sean.mullan 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
> >
> > Attributes.java:
> >
> > - Line 377: Too long, add a break.
> >
> > Otherwise fine.
> >
> > I don't have a strong opinion on making Manifest.jarFilename final or a
> > different property name.
> >
> > Thanks
> > Max
> >
> > > On Sep 11, 2018, at 5:07 PM, Baesken, Matthias
> > <matthias.baesken at sap.com> wrote:
> > >
> > > Hello, please check the new webrev  :
> > >
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/
> > >
> > > I kept the jarPath   category name .
> > >
> > > Best regards, Matthias
> > >
> > >
> > >> -----Original Message-----
> > >> From: Langer, Christoph
> > >> Sent: Montag, 10. September 2018 21:30
> > >> To: Weijun Wang <weijun.wang at oracle.com>; Baesken, Matthias
> > >> <matthias.baesken at sap.com>
> > >> Cc: Sean Mullan <sean.mullan 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
> > >>
> > >> Hi,
> > >>
> > >>>> do you think we need property
> jdk.includeInExceptions=jar<File/Path>
> > at
> > >>> all, if we don't resolve the absolute path?
> > >>>
> > >>> I think so. File path is still sensitive.
> > >>>
> > >>> In fact, I tend to believe people usually use absolute paths for JAR files
> > (or
> > >>> maybe made absolute by using a file:// URL somewhere inside JDK).
> Do
> > >> you
> > >>> really see relative jar paths while testing this code change?
> > >>
> > >> I agree.
> > >>
> > >>>> small remark to the code:
> > >>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java
> > >>>> 36     public static String privilegeGetOverridable(String propName) {
> > >>>>
> > >>>> Should that method really be public? At the moment it doesn't seem
> to
> > >> be
> > >>> used outside of SecurityProperties.
> > >>>
> > >>> I like it to be public. There are quite some other such system/security
> > >>> properties (Ex: jdk.serialFilter) that can make use of this method.
> > >>
> > >> Ok, maybe it should be named "priviledgedGetOverridable" then.
> > >>
> > >> @Matthias:
> > >> Further small cleanups, as you touch the files:
> > >> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can
> > >> remove "import java.util.Iterator;"
> > >>
> > >> src/java.base/share/classes/sun/net/util/SocketExceptions.java:
> > >> line 41: indentation is ridiculously long, I think it should be 8 chars
> > >>
> > >> src/java.base/share/classes/sun/security/util/SecurityProperties.java:
> > >> Indentation of lines 38-45 is too deep, should be 12.
> > >> The 2 methods could use a brief Javadoc.
> > >>
> > >> Best regards
> > >> Christoph
> > >
> 


From roger.riggs at oracle.com  Tue Sep 11 13:09:02 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 11 Sep 2018 09:09:02 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
Message-ID: <fa65bc9c-3986-108d-c395-9f2dc42a84db@oracle.com>

Hi Alan,


On 9/11/18 5:24 AM, Alan Bateman wrote:
> On 10/09/2018 21:55, Roger Riggs wrote:
>> Nope! there's quoting on Windows that gets short changed with that 
>> work around.
>>
>> Other opinions?, Suggestions?
> One suggestion is reduce this down to one method that returns a stream 
> rather than a collection. It could work lazily if you want. Something 
> like:
>
> ? Stream<String> splitSearchPath(String input)
>
> is a lot more flexible (in my view) and the places where we use Path 
> objects can use .map(Path::of).

Streams are fine and easy to get from a List; but overall are a much 
higher overhead than the list itself.
And they can't be stored or re-used. Which would mean re-parsing the 
string again.
>
> In passing, I see the current patch changes the UCP constructor that 
> is used for supporting -Xbootclasspath/a. That that will to be checked 
> to see if it has any impact on startup.
It uses the internal api that returns a String[] and and should have the 
same performance profile
as the current impl.? This is definately a place where a Stream impl 
would have a negative impact.

Thanks, Roger

>
> -Alan
>


From roger.riggs at oracle.com  Tue Sep 11 13:18:48 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 11 Sep 2018 09:18:48 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
Message-ID: <17031a0d-095a-7daf-8f12-73aba77a7cd0@oracle.com>

Hi Chris,

On 9/11/18 7:50 AM, Chris Hegarty wrote:
>> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 10/09/2018 21:55, Roger Riggs wrote:
>>> Nope! there's quoting on Windows that gets short changed with that work around.
>>>
>>> Other opinions?, Suggestions?
>> One suggestion is reduce this down to one method that returns a stream rather than a collection. It could work lazily if you want. Something like:
>>
>>    Stream<String> splitSearchPath(String input)
> I agree with Alan, this seems like the lowest-order primitive.
How can that be? The Stream creates a lot more objects and takes even 
more to use it.
It can't be stored or re-used and has higher overhead that can't easily 
be understood.
>
> I refreshed my memory of search path splitting from the `jmod` tool,
> where such an API would be useful ( if we weren?t using joptsimple ).
> There are two separate use cases, ClassPathConverter, and
> DirPathConverter ( in JmodTask ), both of which resolve each String
> path value against the current working directory, and do some
> context specific validation.
Command line tools are more likely to resolve against the current directory
List<String> is least common but still pushes more to the developer.

$.02, Roger

>
> -Chris.
>
>


From chris.hegarty at oracle.com  Tue Sep 11 14:02:32 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 11 Sep 2018 15:02:32 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <17031a0d-095a-7daf-8f12-73aba77a7cd0@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
 <17031a0d-095a-7daf-8f12-73aba77a7cd0@oracle.com>
Message-ID: <718AF1CC-EA58-4C3B-9FAF-654FC6C05F8F@oracle.com>


> On 11 Sep 2018, at 14:18, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 9/11/18 7:50 AM, Chris Hegarty wrote:
>>> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 10/09/2018 21:55, Roger Riggs wrote:
>>>> Nope! there's quoting on Windows that gets short changed with that work around.
>>>> 
>>>> Other opinions?, Suggestions?
>>> One suggestion is reduce this down to one method that returns a stream rather than a collection. It could work lazily if you want. Something like:
>>> 
>>>   Stream<String> splitSearchPath(String input)
>> I agree with Alan, this seems like the lowest-order primitive.
> How can that be? The Stream creates a lot more objects and takes even more to use it.

I guess it depends on the use-case that you are trying to 
address. In the cases that I sited, a Stream would likely be
more appropriate since the calling code requires to iterate
over the entries, rather than store them as-is. You are
probably thinking of different use-cases.

> It can't be stored or re-used and has higher overhead that can't easily be understood.

.collect(toList()) - which, again, depending on use-case
may be more or less common than entries.stream().

>> I refreshed my memory of search path splitting from the `jmod` tool,
>> where such an API would be useful ( if we weren?t using joptsimple ).
>> There are two separate use cases, ClassPathConverter, and
>> DirPathConverter ( in JmodTask ), both of which resolve each String
>> path value against the current working directory, and do some
>> context specific validation.
> Command line tools are more likely to resolve against the current directory
> List<String> is least common but still pushes more to the developer.

Exactly. My comments are from the perspective of writing a
command line tool, since that is the only direct experience
I have with such functionality. You may have different use-
cases in mind.

-Chris.

From Alan.Bateman at oracle.com  Tue Sep 11 14:29:06 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Sep 2018 15:29:06 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <fa65bc9c-3986-108d-c395-9f2dc42a84db@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <fa65bc9c-3986-108d-c395-9f2dc42a84db@oracle.com>
Message-ID: <64edb939-d0c3-b093-c4de-31fa5a06cb69@oracle.com>

On 11/09/2018 14:09, Roger Riggs wrote:
>
> Streams are fine and easy to get from a List; but overall are a much 
> higher overhead than the list itself.
> And they can't be stored or re-used. Which would mean re-parsing the 
> string again.
I think returning Stream<String> will provide the most flexibility. The 
example usages in the webrev mostly want the elements in an array or 
they want to perform an action for each element and that is easily done 
with pipelines such as:

splitSearchPath(input).map(Path::of).toArray(Path[]::new)

splitSearchPath(input).map(Path::of).forEach(...)

If something wants to elements in a List or needs to cache the result 
then they can use a collector.

I agree we might need something special to optimize JDK startup but I 
don't think these cases should influence the API.

-Alan











From weijun.wang at oracle.com  Tue Sep 11 14:44:06 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Sep 2018 22:44:06 +0800
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
Message-ID: <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>

Is the wildcard character allowed in the input?

I'm thinking of the wildcard support in classpath.

--Max

> On Sep 11, 2018, at 2:16 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review the API and implementation of an API to parse Path strings.
> Two methods are added to java.nio.file.Paths to parse a string using the path separator delimiter
> and return either List<String> or List<Path>.  Empty path elements are ignored.
> 
> For compatibility with current URLClassPath behavior the internal implementation handles
> replacement of empty paths.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
> 
> CSR:
>   https://bugs.openjdk.java.net/browse/JDK-8208208
> 
> Thanks, Roger
> 


From roger.riggs at oracle.com  Tue Sep 11 14:48:37 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 11 Sep 2018 10:48:37 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
Message-ID: <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>

Hi,

What would the use case be for that?

A search path is usually just a sequence of file paths;? wildcard 
expansion is not includes.
Wildcards are significant only in shell contexts, though the expansion 
is done by the shell on Unix and by the application on Windows;? it 
would add a fair bit of complexity.

Roger


On 9/11/18 10:44 AM, Weijun Wang wrote:
> Is the wildcard character allowed in the input?
>
> I'm thinking of the wildcard support in classpath.
>
> --Max
>
>> On Sep 11, 2018, at 2:16 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> Please review the API and implementation of an API to parse Path strings.
>> Two methods are added to java.nio.file.Paths to parse a string using the path separator delimiter
>> and return either List<String> or List<Path>.  Empty path elements are ignored.
>>
>> For compatibility with current URLClassPath behavior the internal implementation handles
>> replacement of empty paths.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
>>
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8208208
>>
>> Thanks, Roger
>>


From weijun.wang at oracle.com  Tue Sep 11 14:53:15 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Sep 2018 22:53:15 +0800
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
 <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>
Message-ID: <FB7AB36C-7332-4BEE-89A7-04E984AF9841@oracle.com>

https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762

This is not about the wildcard parsed by the shell. The bug synopsis mentions "classpath" and I am just curious if it covers this feature. I don't have my own user case for it.

--Max

> On Sep 11, 2018, at 10:48 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi,
> 
> What would the use case be for that?
> 
> A search path is usually just a sequence of file paths;  wildcard expansion is not includes.
> Wildcards are significant only in shell contexts, though the expansion is done by the shell on Unix and by the application on Windows;  it would add a fair bit of complexity.
> 
> Roger
> 
> 
> On 9/11/18 10:44 AM, Weijun Wang wrote:
>> Is the wildcard character allowed in the input?
>> 
>> I'm thinking of the wildcard support in classpath.
>> 
>> --Max
>> 
>>> On Sep 11, 2018, at 2:16 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>> 
>>> Please review the API and implementation of an API to parse Path strings.
>>> Two methods are added to java.nio.file.Paths to parse a string using the path separator delimiter
>>> and return either List<String> or List<Path>.  Empty path elements are ignored.
>>> 
>>> For compatibility with current URLClassPath behavior the internal implementation handles
>>> replacement of empty paths.
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
>>> 
>>> CSR:
>>>   https://bugs.openjdk.java.net/browse/JDK-8208208
>>> 
>>> Thanks, Roger
>>> 
> 


From forax at univ-mlv.fr  Tue Sep 11 15:00:47 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 11 Sep 2018 17:00:47 +0200 (CEST)
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <64edb939-d0c3-b093-c4de-31fa5a06cb69@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <fa65bc9c-3986-108d-c395-9f2dc42a84db@oracle.com>
 <64edb939-d0c3-b093-c4de-31fa5a06cb69@oracle.com>
Message-ID: <1780508946.827689.1536678047079.JavaMail.zimbra@u-pem.fr>

I like splitSearchPath.

If think splitSearchPath should be a static method of java.io.File, perhaps with another variant in java.nio.file.Files also named splitSearchPath that returns a Stream of Path.

R?mi

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "Roger Riggs" <roger.riggs at oracle.com>, "jonathan gibbons" <jonathan.gibbons at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 11 Septembre 2018 16:29:06
> Objet: Re: 8207690: Parsing API for classpath and similar path strings

> On 11/09/2018 14:09, Roger Riggs wrote:
>>
>> Streams are fine and easy to get from a List; but overall are a much
>> higher overhead than the list itself.
>> And they can't be stored or re-used. Which would mean re-parsing the
>> string again.
> I think returning Stream<String> will provide the most flexibility. The
> example usages in the webrev mostly want the elements in an array or
> they want to perform an action for each element and that is easily done
> with pipelines such as:
> 
> splitSearchPath(input).map(Path::of).toArray(Path[]::new)
> 
> splitSearchPath(input).map(Path::of).forEach(...)
> 
> If something wants to elements in a List or needs to cache the result
> then they can use a collector.
> 
> I agree we might need something special to optimize JDK startup but I
> don't think these cases should influence the API.
> 
> -Alan

From roger.riggs at oracle.com  Tue Sep 11 15:05:23 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 11 Sep 2018 11:05:23 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <FB7AB36C-7332-4BEE-89A7-04E984AF9841@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
 <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>
 <FB7AB36C-7332-4BEE-89A7-04E984AF9841@oracle.com>
Message-ID: <a83006a7-ef41-dde3-7310-11c5e3a79145@oracle.com>

Hi Max,

Right, that is a description of the shell environment on Windows and how 
the java launcher behaves.
On Windows the launcher expands wildcards when evaluating classpath from 
the environment
and the command line args.? After they are expanded the java.class.path 
property is set.
The proposed API can be used with other paths and does not expand wildcards.

Regards, Roger

On 9/11/18 10:53 AM, Weijun Wang wrote:
> https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762
>
> This is not about the wildcard parsed by the shell. The bug synopsis mentions "classpath" and I am just curious if it covers this feature. I don't have my own user case for it.
>
> --Max
>
>> On Sep 11, 2018, at 10:48 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi,
>>
>> What would the use case be for that?
>>
>> A search path is usually just a sequence of file paths;  wildcard expansion is not includes.
>> Wildcards are significant only in shell contexts, though the expansion is done by the shell on Unix and by the application on Windows;  it would add a fair bit of complexity.
>>
>> Roger
>>
>>
>> On 9/11/18 10:44 AM, Weijun Wang wrote:
>>> Is the wildcard character allowed in the input?
>>>
>>> I'm thinking of the wildcard support in classpath.
>>>
>>> --Max
>>>
>>>> On Sep 11, 2018, at 2:16 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>
>>>> Please review the API and implementation of an API to parse Path strings.
>>>> Two methods are added to java.nio.file.Paths to parse a string using the path separator delimiter
>>>> and return either List<String> or List<Path>.  Empty path elements are ignored.
>>>>
>>>> For compatibility with current URLClassPath behavior the internal implementation handles
>>>> replacement of empty paths.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
>>>>
>>>> CSR:
>>>>    https://bugs.openjdk.java.net/browse/JDK-8208208
>>>>
>>>> Thanks, Roger
>>>>


From weijun.wang at oracle.com  Tue Sep 11 15:09:58 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Sep 2018 23:09:58 +0800
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <a83006a7-ef41-dde3-7310-11c5e3a79145@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
 <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>
 <FB7AB36C-7332-4BEE-89A7-04E984AF9841@oracle.com>
 <a83006a7-ef41-dde3-7310-11c5e3a79145@oracle.com>
Message-ID: <D1EC73F0-A8E1-4680-9BF7-1BCFB86A1831@oracle.com>

Clarified.

So classpath can call this new method first and then expand * to all JAR files. This is fine.

Thanks
Max

> On Sep 11, 2018, at 11:05 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi Max,
> 
> Right, that is a description of the shell environment on Windows and how the java launcher behaves.
> On Windows the launcher expands wildcards when evaluating classpath from the environment
> and the command line args.  After they are expanded the java.class.path property is set.
> The proposed API can be used with other paths and does not expand wildcards.
> 
> Regards, Roger
> 
> On 9/11/18 10:53 AM, Weijun Wang wrote:
>> https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html#A1100762
>> 
>> This is not about the wildcard parsed by the shell. The bug synopsis mentions "classpath" and I am just curious if it covers this feature. I don't have my own user case for it.
>> 
>> --Max
>> 
>>> On Sep 11, 2018, at 10:48 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> What would the use case be for that?
>>> 
>>> A search path is usually just a sequence of file paths;  wildcard expansion is not includes.
>>> Wildcards are significant only in shell contexts, though the expansion is done by the shell on Unix and by the application on Windows;  it would add a fair bit of complexity.
>>> 
>>> Roger
>>> 
>>> 
>>> On 9/11/18 10:44 AM, Weijun Wang wrote:
>>>> Is the wildcard character allowed in the input?
>>>> 
>>>> I'm thinking of the wildcard support in classpath.
>>>> 
>>>> --Max
>>>> 
>>>>> On Sep 11, 2018, at 2:16 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>> 
>>>>> Please review the API and implementation of an API to parse Path strings.
>>>>> Two methods are added to java.nio.file.Paths to parse a string using the path separator delimiter
>>>>> and return either List<String> or List<Path>.  Empty path elements are ignored.
>>>>> 
>>>>> For compatibility with current URLClassPath behavior the internal implementation handles
>>>>> replacement of empty paths.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
>>>>> 
>>>>> CSR:
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8208208
>>>>> 
>>>>> Thanks, Roger
>>>>> 
> 


From hohensee at amazon.com  Tue Sep 11 15:41:29 2018
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 11 Sep 2018 15:41:29 +0000
Subject: SSL session cache default maximum number of entries
Message-ID: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>

The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we?re running into situations where the cache ends up with several million entries when the 24 hours are up. They?re then all invalidated at the same time, resulting in multi-minute pauses (effectively service failures). We?ve experimented with using 10k as the default maximum number of entries with good results (i.e., no latency increases due to sessions falling out of the cache). It?s late and a long shot for JDK11: we?d love to see it changed there because 11 is an LTS release and this is, at least nominally, a behavior change which might not be acceptable in 11u. What do people think?

Thanks,

Paul


From ullenboom at gmail.com  Mon Sep 10 22:18:42 2018
From: ullenboom at gmail.com (Christian Ullenboom)
Date: Tue, 11 Sep 2018 00:18:42 +0200
Subject: ByteArrayOutputStream should not have a new writeBytes method in Java
 11
Message-ID: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>

1. There is write(byte[]) already
2. even if, it should not be byte b[] but byte[] b

From erik.joelsson at oracle.com  Tue Sep 11 15:57:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Sep 2018 08:57:44 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
Message-ID: <b99c944b-620b-7115-830e-0d75188941db@oracle.com>

Hello Severin,

Even if using the macro, I still think you need to add a condition on 
the compiler types where the switch can be reasonably expected to exist.

/Erik


On 2018-09-11 05:02, Severin Gehwolf wrote:
> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>> I see. I was not aware of that issue, but we clearly need to file a bug
>> for it and fix it. In this case I think it's fine to us the macro however.
> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>
> Micro-benchmark results from running [1] for x86_64 and ppc64le are
> here (-O2 is sufficient it seems):
>
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>
> More thoughts?
>
> Thanks,
> Severin
>
> [1] https://github.com/gromero/strictmath/
>


From sean.mullan at oracle.com  Tue Sep 11 16:02:44 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 11 Sep 2018 12:02:44 -0400
Subject: SSL session cache default maximum number of entries
In-Reply-To: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
Message-ID: <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>

cross-posting to security-dev since this is related to SSL/TLS.

On 9/11/18 11:41 AM, Hohensee, Paul wrote:
> The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we?re running into situations where the cache ends up with several million entries when the 24 hours are up. They?re then all invalidated at the same time, resulting in multi-minute pauses (effectively service failures). We?ve experimented with using 10k as the default maximum number of entries with good results (i.e., no latency increases due to sessions falling out of the cache). It?s late and a long shot for JDK11: we?d love to see it changed there because 11 is an LTS release and this is, at least nominally, a behavior change which might not be acceptable in 11u. What do people think?
> 
> Thanks,
> 
> Paul
> 

From scolebourne at joda.org  Tue Sep 11 16:04:01 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 11 Sep 2018 17:04:01 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
Message-ID: <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>

On Tue, 11 Sep 2018 at 10:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 10/09/2018 21:55, Roger Riggs wrote:
> > Nope! there's quoting on Windows that gets short changed with that
> > work around.
> >
> > Other opinions?, Suggestions?
> One suggestion is reduce this down to one method that returns a stream
> rather than a collection. It could work lazily if you want. Something like:
>
>    Stream<String> splitSearchPath(String input)
>
> is a lot more flexible (in my view) and the places where we use Path
> objects can use .map(Path::of).

This is a broader question for new methods in the JDK, not just this
one. I don't think anyone has come up with a "style guide" for when to
use Stream returning as opposed to list-returning methods.

What I can say is that I think List is the better fit here, because:
- the result is not large
- the result may well be stored somewhere (method should guarantee
result is immutable)
- a List is simpler conceptually than Stream as a result type (eg.
serial vs parallel)

Personally, I only tend to return Stream if I the particular method is
returning a very large data set.

Stephen

From sgehwolf at redhat.com  Tue Sep 11 16:14:33 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Sep 2018 18:14:33 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
Message-ID: <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>

Hi Erik,

Thanks for the review!

On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
> Hello Severin,
> 
> Even if using the macro, I still think you need to add a condition on 
> the compiler types where the switch can be reasonably expected to exist.

How about this?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/

Thanks,
Severin

> On 2018-09-11 05:02, Severin Gehwolf wrote:
> > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> > > I see. I was not aware of that issue, but we clearly need to file a bug
> > > for it and fix it. In this case I think it's fine to us the macro however.
> > 
> > OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
> > 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
> > 
> > Micro-benchmark results from running [1] for x86_64 and ppc64le are
> > here (-O2 is sufficient it seems):
> > 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> > 
> > More thoughts?
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://github.com/gromero/strictmath/
> > 
> 
> 


From Michael.Rasmussen at roguewave.com  Tue Sep 11 16:17:32 2018
From: Michael.Rasmussen at roguewave.com (Michael Rasmussen)
Date: Tue, 11 Sep 2018 16:17:32 +0000
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
Message-ID: <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>

See the comments here https://bugs.openjdk.java.net/browse/JDK-8180410


/Michael




________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Christian Ullenboom <ullenboom at gmail.com>
Sent: 11 September 2018 01:18:42
To: core-libs-dev at openjdk.java.net
Subject: ByteArrayOutputStream should not have a new writeBytes method in Java 11

1. There is write(byte[]) already
2. even if, it should not be byte b[] but byte[] b

From mark.reinhold at oracle.com  Tue Sep 11 16:35:12 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Sep 2018 09:35:12 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <a83006a7-ef41-dde3-7310-11c5e3a79145@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <8F4A5944-B923-4AB3-9FB4-CB683690A431@oracle.com>
 <43d88bb5-fa63-46f1-e0bd-06dadf6c9f67@oracle.com>
 <FB7AB36C-7332-4BEE-89A7-04E984AF9841@oracle.com>
 <a83006a7-ef41-dde3-7310-11c5e3a79145@oracle.com>
Message-ID: <20180911093512.660639634@eggemoggin.niobe.net>

2018/9/11 8:05:23 -0700, roger.riggs at oracle.com:
> Right, that is a description of the shell environment on Windows and how 
> the java launcher behaves.
> On Windows the launcher expands wildcards when evaluating classpath from 
> the environment
> and the command line args. After they are expanded the java.class.path 
> property is set.

Class-path wildcards are expanded by the launcher and the compiler, on
all platforms, to include all files in a specific directory that end in
`.jar` or `.JAR`.  In most shells you need to quote them so that the
shell doesn?t expand them, e.g., `--class-path lib/\*:.`.

- Mark

From mark.reinhold at oracle.com  Tue Sep 11 16:49:52 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Sep 2018 09:49:52 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
Message-ID: <20180911094952.979472405@eggemoggin.niobe.net>

2018/9/11 4:50:49 -0700, chris.hegarty at oracle.com:
>> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 10/09/2018 21:55, Roger Riggs wrote:
>>> Nope! there's quoting on Windows that gets short changed with that work around.
>>> 
>>> Other opinions?, Suggestions?
>> 
>> One suggestion is reduce this down to one method that returns a
>> stream rather than a collection. It could work lazily if you
>> want. Something like:
>> 
>>  Stream<String> splitSearchPath(String input)
> 
> I agree with Alan, this seems like the lowest-order primitive.

Agreed, but it begs a question that applies to all these alternatives:
Why does this API belong in java.nio.file.Paths?

In other words, search paths are a different abstraction from filesystem
paths.  Should they have their own class, even if it only winds up with
a couple of static utility methods?  java.nio.file.SearchPath?

    public class SearchPath {
        public static Stream<String> splitToStream(String searchPath);
        public static List<Path> splitToPaths(String searchPath);
        public static String join(Collection<String>);
    }

- Mark

From thomas.stuefe at gmail.com  Tue Sep 11 17:27:13 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 11 Sep 2018 19:27:13 +0200
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC
 instead of close()
Message-ID: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>

Hi all,

May I please have reviews for this small fix:

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

patch (full): http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.00/webrev/
patch (minimal alternative):
http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.minimal/webrev/

See also prior discussion:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055173.html

Submit tests ran with full patch successfully through.

---

Background:

After fork()/vfork() and before exec(), the child process needs to
close all inherited file descriptors apart from the stdin/out/err pipe
ends. We do this by iterating thru all file descriptors in
/proc/<pid>/fd or whatever the equivalent is on that platform. This is
done using opendir(), readdir().

We then close all these file descriptors using close().

The problem with that technique is that we may accidentally close the
file descriptor opendir() is using internally to read the directory
content of /proc/<pid>/fd, thereby sawing off the branch we are
sitting on. The coding does some magic to attempt to prevent this:

<quote>
86    /* We're trying to close all file descriptors, but opendir() might
87     * itself be implemented using a file descriptor, and we certainly
88     * don't want to close that while it's in use.  We assume that if
89     * opendir() is implemented using a file descriptor, then it uses
90     * the lowest numbered file descriptor, just like open().  So we
91     * close a couple explicitly.  */
92
93    close(from_fd);          /* for possible use by opendir() */
94    close(from_fd + 1);      /* another one for good luck */

...
108    while ((dirp = readdir64(dp)) != NULL) {
109        int fd;
110        if (isAsciiDigit(dirp->d_name[0]) &&
111            (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd +
2)Improve "close all filedescriptors" coding.
112            close(fd);
113    }

</quote>

This workaround can be removed if, instead of outright closing the
file descriptor in the loop, we were to set the file descriptor to
FD_CLOEXEC. Closing all descriptors would be defered to the actual
exec() call some milliseconds later.

----

The patch changes the close() call to fcntl(FD_CLOEXEC). This removes
the need for the workaround as described.

In addition to that, the full version of the patch also adds error
handling to the readdir() loop.

But note that this exposes us to a behavioral change should we run
into a readdir() error:

- currently, we would leave the remaining file descriptors quietly
unclosed. This usually would have no effect, but in rare cases may
lead to difficult-to-analyze errors when child processes accidentally
disturb parent process IO.

- With this patch, we will fail if readdir fails. However, we do not
just yet fail the Runtime.exec() call, but enter a fallback code
section here:

364     /* close everything */
365     if (closeDescriptors() == 0) { /* failed,  close the old way */
366         int max_fd = (int)sysconf(_SC_OPEN_MAX);
367         int fd;
368         for (fd = FAIL_FILENO + 1; fd < max_fd; fd++)
369             if (close(fd) == -1 && errno != EBADF)
370                 goto WhyCantJohnnyExec;
371     }

I am not convinced this is a good fallback. _SC_OPEN_MAX depends on
ulimit -Hn and may be high. On my Ubuntu 16.4 box, default value after
installation is 1048576. When we hit this fallback code, it takes
almost a full second to spawn a single child process. In fork
intensive scenarios this can get pretty bad.

What do you think?

Thanks & Best Regards,

Thomas

From erik.joelsson at oracle.com  Tue Sep 11 17:30:58 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Sep 2018 10:30:58 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
Message-ID: <2fe884fc-843b-ee59-101d-8148a1407408@oracle.com>

Looks good, thanks!

/Erik


On 2018-09-11 09:14, Severin Gehwolf wrote:
> Hi Erik,
>
> Thanks for the review!
>
> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> Even if using the macro, I still think you need to add a condition on
>> the compiler types where the switch can be reasonably expected to exist.
> How about this?
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
>
> Thanks,
> Severin
>
>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>>>
>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>> here (-O2 is sufficient it seems):
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>>>
>>> More thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] https://github.com/gromero/strictmath/
>>>
>>


From thomas.stuefe at gmail.com  Tue Sep 11 17:34:02 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 11 Sep 2018 19:34:02 +0200
Subject: Question about libjava/childproc.c
In-Reply-To: <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>
References: <CAA-vtUwmiy=U3+ZLY7d6CXyB2t_5tfU4Bq2C-A6cc48xTK-8eg@mail.gmail.com>
 <9b6a38b4-3fe1-eeae-5793-bc303ba50428@oracle.com>
 <CA+kOe0__YDXUSaK1RwiAGXCLXoZmRjj2=Zg6vkTgJv_PTLLNjA@mail.gmail.com>
 <CAA-vtUydsAnWhS9dpUAuQTtCa0Wv6oH6cTXF7f6eDQej=y4s0g@mail.gmail.com>
 <CA+kOe08Hz_DN-Zcwn+B14rkFag1JUW032ySUizDyc17iN13+=Q@mail.gmail.com>
 <CAA-vtUx86s=3sqiTKT+aWG7rAL6Pmt61xOjGqLBcoBdnwBA6DQ@mail.gmail.com>
 <CA+kOe0_nsd_GxVOnxMZP5E1rso5UFbvNPTbe+AKsZn55Ld4DkQ@mail.gmail.com>
Message-ID: <CAA-vtUxak2zTC5mvLHitL-+oKHeXqu9dpik0mNU+6R-utTD-Qg@mail.gmail.com>

Hi Martin, Alan,

On Sun, Sep 9, 2018 at 2:34 AM, Martin Buchholz <martinrb at google.com> wrote:
>
>
> On Wed, Sep 5, 2018 at 11:43 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>>
>> On Wed, Sep 5, 2018 at 6:43 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>> > So before the readdir loop we should set errno to 0.  Then when readdir
>> > returns NULL, we should check whether errno is non-zero.
>> >
>>
>> Note that if we fix this, we may run into errors which were hidden
>> before, namely if we really accidentally did close the file descriptor
>> used by opendir(). Currently, even if some file descriptors remain
>> unclosed, that may not necessarily lead to an error. But with your
>> suggested error handling we would straight away fail.
>>
>> Therefore I would combine both fixes - add readdir error handling and
>> also change to fcntl(FD_CLOEXEC).
>>
>
> I support this plan.  We expect most file descriptors to already have the
> FD_CLOEXEC flag set, so a useful optimization is to set the flag only when
> not already set.
>
> Probably the code should be conditional on defined(FD_CLOEXEC).
>

Great. I just posted an RFR.

>>
>> > ---
>> >
>> > We do have a way of reporting errno to the parent.  See
>> > WhyCantJohnnyExec.
>>
>> Ah I see.
>>
>> Btw, do you know what happens when we modify errno in a vforked child
>> process? Would that not modify errno in the parent process too? (errno
>> is probably implemented as thread local variable, and since the parent
>> thread sleeps until we exec this may still be okay, or?).
>>
>
> It's a good question.  vfork is typically underspecified, so it is plausible
> that changing errno in the child affects the parent.  I think we should
> simply make sure that the parent code is robust against this (as it
> typically is - you check errno when a system API has already returned an
> indication of an error)
>

This whole vfork thing is a rabbit hole. I spent some time with it and
will post the results in a separate mail.

As for errno, it gets actually propagated to the parent - but since
the parent forking thread is waiting in vfork, it will return from
vfork and then it just does not care (since vfork was successful there
is no reason to look at errno).

Its actually funny. Cool way to do IPC :)

>>
>> ---
>>
>> A bit more background, if you are interested:
>>
>> A long time ago, at SAP we swapped Oracle's implementation of
>> Runtime.exec on Unix against a completely homegrown one. The reason
>> was that we needed a really robust implementation for our customers,
>> and with the then current implementation we kept running into
>> limitations and pathological corner cases. Especially on outlier
>> platforms like HPUX or AS/400.
>>
>> This was long before OpenJDK existed, so there was no way for us to
>> just fix the coding upstream.
>
>
> In 2005 I was the primary maintainer of the subprocess code at Sun, and
> there is a good chance you could have gotten changes in if you had asked me!

:(  How often I wished I could talk to someone about stuff like this.
But well, here we are. Thank god for Open Source.


..Thomas

From thomas.stuefe at gmail.com  Tue Sep 11 17:51:56 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 11 Sep 2018 19:51:56 +0200
Subject: Runtime.exec : vfork() concerns and a fix proposal
Message-ID: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>

Hi all,

I wanted to gauge opinions on the following issue:

Runtime.exec, on Linux, uses vfork(2) by default. It gives us better
performance compared with fork() and robustness in constrained memory
situations.

But as we know vfork() can be dangerous if used incorrectly. In the
child process before exec'ing, we live in the memory of the parent
process. If we are not very careful we can influence or crash the
parent process.

According to POSIX pretty much the only thing the child process is
allowed to do after vfork(2) is to exec(3) immediately; if that fails,
you must call _exit(2).

http://pubs.opengroup.org/onlinepubs/009604599/functions/vfork.html

However, in the openjdk we do a number of things beyond that:

- stdin,out,err pipe handling business
- closing all file descriptors
- we change the working directory
- we may actually modify errno manually
- in case exec fails, we communicate the error back to the parent using pipe.

This involves calling a number of libc functions beyond exec(), namely
read, close, dup2, opendir/readdir, write, chdir... It also needs a
bit of stack, since we assemble path names.

--

I was curious whether there were any real issues, so I tested (on
Ubuntu 16.4) and found:

1) A crash - any crash - in the child process before exec() will kill
the parent jvm dead. Weirdly enough, we do not even enter our error
handling, but seem to die instantly with the default "Segmentation
Fault".

2) Signals received by the child process before exec() influence the
parent process. For example:
 - SIGINT set to the child ends both parent and child, immediately
 - SIGABRT aborts both child and parent
 - any error signal sent to the child lead to the behavior described at (1)

3) A stack overflow in the child before exec() also kills the parent.
Unsurprising, since guard page hit -> segfault -> see (1).

4) more amusing, setting errno in the child before exec() changes the
errno in the parent process. propagates to the parent process.
But since errno is thread local and the thread in the parent process
is waiting in vfork() and will, upon return, not look at errno (after
all, vfork succeeded) this causes no trouble.

There may be more issues, but these were the ones I tested.

In all cases I counter-tested with fork() instead of vfork() and as
expected  with fork() the parent process stays unaffected as it should
be.

-------------

Whether you think these issues are worth solving is an open question.

All these cases may happen in the wild (well, apart from
crash-by-programming-error if one assumes the program to be really bug
free) albeit with a very small probability. But once these bugs occur,
they can be very difficult to analyse. So fixing this may be
worthwhile.

At SAP, we opted for robustness, so we changed the Runtime.exec()
implementation to deal with vfork() issues. Basically, we employ the
exec-twice technique:

- in the child, after the vfork(), we immediately exec() into a little
bootstrap binary ("forkhelper").
- Now we are safe in the sense that we do not share memory with the
parent process anymore
- Then, parent process communicates with the child via pipes and gives
it all information needed to do the "real" exec: environ, current dir,
arguments... .
- Now the child exec's a second time, this time into the real target binary.

The point of this technique is that we minimize the window in the
child between vfork and the first exec. In fact, we are now fully
POSIX compliant. This solves the described pathological cases.

It has some other advantages too, e.g. allowing for better error
handling and tracing in the Runtime.exec() area. Performance-wise it
depends: we exec twice, so we pay twice. However, since the parent
continues execution after the first exec, it spends less time waiting
on the child process, which can make a difference if there are many
file descriptors open.

---

Checking opinions here. Do you think we are okay with our current
implementation or would a change as described above be welcome in the
OpenJDK too?

Thanks, and Best Regards, Thomas

From david.lloyd at redhat.com  Tue Sep 11 18:29:38 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 11 Sep 2018 13:29:38 -0500
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
Message-ID: <CANghgrRH8qiHU-2+AFgT4ktcudegGHnVnGXXbkG+7gyU=Nf1pQ@mail.gmail.com>

I think this is a cool idea.  Do you have any performance numbers?
On Tue, Sep 11, 2018 at 12:52 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi all,
>
> I wanted to gauge opinions on the following issue:
>
> Runtime.exec, on Linux, uses vfork(2) by default. It gives us better
> performance compared with fork() and robustness in constrained memory
> situations.
>
> But as we know vfork() can be dangerous if used incorrectly. In the
> child process before exec'ing, we live in the memory of the parent
> process. If we are not very careful we can influence or crash the
> parent process.
>
> According to POSIX pretty much the only thing the child process is
> allowed to do after vfork(2) is to exec(3) immediately; if that fails,
> you must call _exit(2).
>
> http://pubs.opengroup.org/onlinepubs/009604599/functions/vfork.html
>
> However, in the openjdk we do a number of things beyond that:
>
> - stdin,out,err pipe handling business
> - closing all file descriptors
> - we change the working directory
> - we may actually modify errno manually
> - in case exec fails, we communicate the error back to the parent using pipe.
>
> This involves calling a number of libc functions beyond exec(), namely
> read, close, dup2, opendir/readdir, write, chdir... It also needs a
> bit of stack, since we assemble path names.
>
> --
>
> I was curious whether there were any real issues, so I tested (on
> Ubuntu 16.4) and found:
>
> 1) A crash - any crash - in the child process before exec() will kill
> the parent jvm dead. Weirdly enough, we do not even enter our error
> handling, but seem to die instantly with the default "Segmentation
> Fault".
>
> 2) Signals received by the child process before exec() influence the
> parent process. For example:
>  - SIGINT set to the child ends both parent and child, immediately
>  - SIGABRT aborts both child and parent
>  - any error signal sent to the child lead to the behavior described at (1)
>
> 3) A stack overflow in the child before exec() also kills the parent.
> Unsurprising, since guard page hit -> segfault -> see (1).
>
> 4) more amusing, setting errno in the child before exec() changes the
> errno in the parent process. propagates to the parent process.
> But since errno is thread local and the thread in the parent process
> is waiting in vfork() and will, upon return, not look at errno (after
> all, vfork succeeded) this causes no trouble.
>
> There may be more issues, but these were the ones I tested.
>
> In all cases I counter-tested with fork() instead of vfork() and as
> expected  with fork() the parent process stays unaffected as it should
> be.
>
> -------------
>
> Whether you think these issues are worth solving is an open question.
>
> All these cases may happen in the wild (well, apart from
> crash-by-programming-error if one assumes the program to be really bug
> free) albeit with a very small probability. But once these bugs occur,
> they can be very difficult to analyse. So fixing this may be
> worthwhile.
>
> At SAP, we opted for robustness, so we changed the Runtime.exec()
> implementation to deal with vfork() issues. Basically, we employ the
> exec-twice technique:
>
> - in the child, after the vfork(), we immediately exec() into a little
> bootstrap binary ("forkhelper").
> - Now we are safe in the sense that we do not share memory with the
> parent process anymore
> - Then, parent process communicates with the child via pipes and gives
> it all information needed to do the "real" exec: environ, current dir,
> arguments... .
> - Now the child exec's a second time, this time into the real target binary.
>
> The point of this technique is that we minimize the window in the
> child between vfork and the first exec. In fact, we are now fully
> POSIX compliant. This solves the described pathological cases.
>
> It has some other advantages too, e.g. allowing for better error
> handling and tracing in the Runtime.exec() area. Performance-wise it
> depends: we exec twice, so we pay twice. However, since the parent
> continues execution after the first exec, it spends less time waiting
> on the child process, which can make a difference if there are many
> file descriptors open.
>
> ---
>
> Checking opinions here. Do you think we are okay with our current
> implementation or would a change as described above be welcome in the
> OpenJDK too?
>
> Thanks, and Best Regards, Thomas



-- 
- DML

From sean.mullan at oracle.com  Tue Sep 11 18:44:07 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 11 Sep 2018 14:44:07 -0400
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <bc465382ae334570878668cc2e5612d3@sap.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
 <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <bc465382ae334570878668cc2e5612d3@sap.com>
Message-ID: <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com>

On 9/11/18 8:14 AM, Langer, Christoph wrote:
> Hi,
> 
> first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there were further Exception details to be added in the area of jar files, they could go under a category "jarDetails" as well. Would you agree? Then, in Manifest.java, the field "jarPathInExceptionText" could be renamed to "detailedExceptions".

Or just "jar" would be my preference. I don't like "jarPath" as that 
sounds too much like a file pathname to me, which we have now removed.

--Sean

From sean.mullan at oracle.com  Tue Sep 11 19:48:30 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 11 Sep 2018 15:48:30 -0400
Subject: SSL session cache default maximum number of entries
In-Reply-To: <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>
References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
 <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>
Message-ID: <f46628d8-6f4e-ea03-99a9-cbcf456f7145@oracle.com>

Hi Paul,

Thank you for bringing this issue to our attention. While we agree that 
this does indeed seem like an issue that should be addressed, it is 
quite late in the JDK 11 schedule, and it does not appear to be a new 
issue introduced in JDK 11. We will be investigating this offline and 
will get back to you as soon as we can with more details. Offhand, I 
think that we would be able to change the default in an update release.

Also, you are probably already be aware of this, but you can use the 
SSLSessionContext.setSessionCacheSize() API as well as the 
"javax.net.ssl.sessionCacheSize" system property to customize the cache 
size.

--Sean

On 9/11/18 12:02 PM, Sean Mullan wrote:
> cross-posting to security-dev since this is related to SSL/TLS.
> 
> On 9/11/18 11:41 AM, Hohensee, Paul wrote:
>> The default value for the maximum number of entries in the SSL session 
>> cache (which is a SoftReference cache) is infinite, and the entry 
>> timeout is 24 hours. With larger heaps, we?re running into situations 
>> where the cache ends up with several million entries when the 24 hours 
>> are up. They?re then all invalidated at the same time, resulting in 
>> multi-minute pauses (effectively service failures). We?ve experimented 
>> with using 10k as the default maximum number of entries with good 
>> results (i.e., no latency increases due to sessions falling out of the 
>> cache). It?s late and a long shot for JDK11: we?d love to see it 
>> changed there because 11 is an LTS release and this is, at least 
>> nominally, a behavior change which might not be acceptable in 11u. 
>> What do people think?
>>
>> Thanks,
>>
>> Paul
>>

From ivan.gerasimov at oracle.com  Tue Sep 11 20:09:17 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 11 Sep 2018 13:09:17 -0700
Subject: RFR (XS) 8210347 : Combine subsequent calls to Set.contains() and
 Set.add()
Message-ID: <ee3d912e-7e78-983a-970b-7554700be571@oracle.com>

Hello!

It's a pico-optimization.

In a few places a call to Set.contains() can be merged with the 
following Set.add().

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347

WEBREV: http://cr.openjdk.java.net/~igerasim/8210347/00/webrev/

Would you please help review the trivial fix?

-- 
With kind regards,
Ivan Gerasimov


From stuart.marks at oracle.com  Tue Sep 11 20:23:41 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 Sep 2018 13:23:41 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
 <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>
Message-ID: <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>

> 2. even if, it should not be byte b[] but byte[] b

Yeah we need to clean occurrences of this anachronistic array declaration from 
the JDK. I noticed a few others nearby. It's startling that a new occurrence has 
crept it. (Or maybe not, perhaps it was done to conform to the nearby code.)

Any volunteers to clean this up?

An interesting exercise would be to write a detector for this declaration style.

s'marks

From stuart.marks at oracle.com  Tue Sep 11 20:54:05 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 Sep 2018 13:54:05 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
Message-ID: <169427a1-7095-d905-c6a6-c367d2fd280a@oracle.com>

Hi Roger,

>  110      * Returns a list of path strings parsed from a string with empty paths removed.

The Unix shell and the Java launcher's -classpath processing treat an empty path 
entry as the current working directory. (I don't know what happens on Windows.) 
Removing empty paths thus would seem to change the semantics of search paths, at 
least on some systems.

s'marks

On 9/10/18 11:16 AM, Roger Riggs wrote:
> Please review the API and implementation of an API to parse Path strings.
> Two methods are added to java.nio.file.Paths to parse a string using the path 
> separator delimiter
> and return either List<String> or List<Path>.? Empty path elements are ignored.
> 
> For compatibility with current URLClassPath behavior the internal implementation 
> handles
> replacement of empty paths.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
> 
> 
> CSR:
>  ? https://bugs.openjdk.java.net/browse/JDK-8208208
> 
> Thanks, Roger
> 

From brian.burkhalter at oracle.com  Tue Sep 11 21:33:11 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Sep 2018 14:33:11 -0700
Subject: RFR (XS) 8210347 : Combine subsequent calls to Set.contains() and
 Set.add()
In-Reply-To: <ee3d912e-7e78-983a-970b-7554700be571@oracle.com>
References: <ee3d912e-7e78-983a-970b-7554700be571@oracle.com>
Message-ID: <A661DD85-B24B-44D1-B414-EA0497626625@oracle.com>

Hello Ivan,

This looks all right to me.

Thanks,

Brian

On Sep 11, 2018, at 1:09 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:

> It's a pico-optimization.
> 
> In a few places a call to Set.contains() can be merged with the following Set.add().
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347
> 
> WEBREV:http://cr.openjdk.java.net/~igerasim/8210347/00/webrev/
> 
> Would you please help review the trivial fix?


From brian.burkhalter at oracle.com  Tue Sep 11 21:35:53 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Sep 2018 14:35:53 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
 <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>
 <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
Message-ID: <C8799FBF-8156-42DF-B452-4B68180081EB@oracle.com>


On Sep 11, 2018, at 1:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

>> 2. even if, it should not be byte b[] but byte[] b
> 
> Yeah we need to clean occurrences of this anachronistic array declaration from the JDK. I noticed a few others nearby. It's startling that a new occurrence has crept it. (Or maybe not, perhaps it was done to conform to the nearby code.)

Mea culpa. Yes, it was done to conform to existing code in the same class.

Brian

From brent.christian at oracle.com  Tue Sep 11 22:41:18 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 11 Sep 2018 15:41:18 -0700
Subject: RFR 12 : 8072130 :
 java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
Message-ID: <f708030e-d825-d016-2b8b-763f71403739@oracle.com>

Hi,

Please review this change to how the platform encoding is determined on 
Mac when loading agents.

Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/

Additional details in the bug report:
https://bugs.openjdk.java.net/browse/JDK-8072130

Some background:
Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding 
hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), 
the JDK uses UTF-8 instead; see JDK-8011194[1].  (This allowed apps 
launched via double-clicked jar to display files correctly for non-ASCII 
languages).

A similar encoding tweak was not made in the code path used for loading 
agents.

This can come into play when an agent jar includes a Boot-Class-Path 
entry containing non-ASCII characters.  iconv() gets setup to convert 
UTF-8 to US-ASCII[2], but will fail when encountering extended 
characters in the entry, so the path in question is not added to the 
bootclasspath[3].  This will likely lead to a ClassNotFoundException.

When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a 
  Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default 
  encoding of UTF-8 (per 8011194) and creates Agent.jar with a 
Boot-Class-Path that includes non-ASCII characters.  But the 
Boot-Class-Path entry gets skipped when loading Agent.jar, so the 
AgentSupport class can't be found.

I propose this be fixed by adding the same UTF-8 encoding adjustment on 
MacOS from 8011194 to the agent loading code path.

An additional note:
This bug was challenging to reproduce, in large part because the 8011194 
code checks for an absent env var (getenv() == null), but not for env 
vars with a blank/empty string value (getenv() == ""), so the test 
environment had to be setup in a specific way (e.g. 'unset LANG' vs 
'export LANG=') to reproduce this bug.  So I'd like to update the code 
to also check for empty string.  I also added a couple small 
improvements to the test.

Thanks!

-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8011194
2. 
http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87
3. 
http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873


From martinrb at google.com  Wed Sep 12 00:13:27 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Sep 2018 17:13:27 -0700
Subject: RFR (XS) 8210347 : Combine subsequent calls to Set.contains() and
 Set.add()
In-Reply-To: <ee3d912e-7e78-983a-970b-7554700be571@oracle.com>
References: <ee3d912e-7e78-983a-970b-7554700be571@oracle.com>
Message-ID: <CA+kOe09ntXCuMfdDKUtD+_M78P8VKWSHjp4nXBBeut_EynZ1VQ@mail.gmail.com>

A meeting of the minds?
http://hg.openjdk.java.net/jdk/jdk/rev/745ce8f5efc8
Looks good!

On Tue, Sep 11, 2018 at 1:09 PM, Ivan Gerasimov
<ivan.gerasimov at oracle.com> wrote:
> Hello!
>
> It's a pico-optimization.
>
> In a few places a call to Set.contains() can be merged with the following
> Set.add().
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210347
>
> WEBREV: http://cr.openjdk.java.net/~igerasim/8210347/00/webrev/
>
> Would you please help review the trivial fix?
>
> --
> With kind regards,
> Ivan Gerasimov
>

From martinrb at google.com  Wed Sep 12 00:19:07 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Sep 2018 17:19:07 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <C8799FBF-8156-42DF-B452-4B68180081EB@oracle.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
 <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>
 <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
 <C8799FBF-8156-42DF-B452-4B68180081EB@oracle.com>
Message-ID: <CA+kOe0-g=D4qH-N-pdUJcU9kJBc6cMxEzA30eWoVKA2CGALyZg@mail.gmail.com>

It's an errorprone warning, for "easy" removal ...  __IF__ you can run
errorprone on the head sources.
I think it's
http://errorprone.info/bugpattern/MixedArrayDimensions

On Tue, Sep 11, 2018 at 2:35 PM, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> On Sep 11, 2018, at 1:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>>> 2. even if, it should not be byte b[] but byte[] b
>>
>> Yeah we need to clean occurrences of this anachronistic array declaration from the JDK. I noticed a few others nearby. It's startling that a new occurrence has crept it. (Or maybe not, perhaps it was done to conform to the nearby code.)
>
> Mea culpa. Yes, it was done to conform to existing code in the same class.
>
> Brian

From martinrb at google.com  Wed Sep 12 00:33:53 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Sep 2018 17:33:53 -0700
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
Message-ID: <CA+kOe0-tEvC1VDg_mZC7U5nCcu7dS7dkGLbjZatB3oXx08fNMg@mail.gmail.com>

https://sourceware.org/ml/libc-alpha/2018-09/msg00120.
Coincidence?

From gromero at linux.vnet.ibm.com  Wed Sep 12 03:51:08 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 12 Sep 2018 00:51:08 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
Message-ID: <47e56a18-a5f7-3583-9f5e-ede471586b8e@linux.vnet.ibm.com>

Hi Severin,

On 09/11/2018 09:02 AM, Severin Gehwolf wrote:
> Micro-benchmark results from running [1] for x86_64 and ppc64le are
> here (-O2 is sufficient it seems):
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> 
> More thoughts?

Thanks a lot for checking it on PPC64.

I did additional tests on a POWER8 using the same microbench. I share the
results below. The numbers are the arithmetic mean of 10 runs. Unit is second.

   1 O3                                   |  O2
   2          Math            StrictMath  |           Math            StrictMath
   3                                      |
   4 acos:    3.0728          3.0728      |  acos:    3.07325         3.07375
   5 asin:    3.0933          3.0916      |  asin:    3.09337         3.0915
   6 atan2:   10.9743         10.9759     |  atan2:   11.2994         11.2977
   7 atan:    7.653           7.6602      |  atan:    7.48463         7.48225
   8 cbrt:    13.444          13.4433     |  cbrt:    13.4535         13.4527
   9 cos:     30.1561         33.9689     |  cos:     30.157          35.1162
  10 cosh:    3.0911          3.1074      |  cosh:    3.09975         3.09088
  11 exp:     1.413           3.0572      |  exp:     1.41313         3.09737
  12 expm1:   3.0281          3.0349      |  expm1:   2.98813         2.98913
  13 hypot:   33.7668         33.7471     |  hypot:   27.9664         27.9675
  14 log10:   4.2213          10.0832     |  log10:   4.221           10.1109
  15 log1p:   9.2886          9.2888      |  log1p:   9.08713         9.08075
  16 log:     3.1362          7.6327      |  log:     3.136           7.633
  17 pow:     13.7787         17.4739     |  pow:     13.7829         17.483
  18 sin:     30.216          33.9733     |  sin:     30.2163         35.1684
  19 sinh:    3.1478          3.152       |  sinh:    3.18638         3.18375
  20 sqrt:    0.665           0.6714      |  sqrt:    0.665           0.671
  21 tan:     31.6409         36.461      |  tan:     31.6385         37.7166
  22 tanh:    3.0753          3.0925      |  tanh:    3.11088         3.10675


Based upon that, it looks like that O3 is better for most of the functions,
specially for sin, cos, and tan.

On the other hand, it looks like that O3 hurts hypot.

Thus it seems -O2 is not quite the same as -O3, but it's not straightforward
to decide which one is better too.

Maybe Andrew can enlight us.

I also CC:ed ppc-aix-port in case somebody there wishes to comment on that.

Thank you.


Best regards,
Gustavo

> Thanks,
> Severin
> 
> [1] https://github.com/gromero/strictmath/
> 


From david.holmes at oracle.com  Wed Sep 12 03:57:03 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Sep 2018 13:57:03 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
Message-ID: <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>

Hi Severin,

Sorry I'm a bit confused now.

Originally for ppc/s390x/aarch64 the optimization level for fdlibm was 
HIGH. But now it will be LOW due to:

   45 ifneq ($(FDLIBM_CFLAGS), )
   46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW

as those platforms will use gcc/clang with support for -ffp-contract and 
so FDLIBM_CFLAGS will not be empty.

??

David

On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
> Hi Erik,
> 
> Thanks for the review!
> 
> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> Even if using the macro, I still think you need to add a condition on
>> the compiler types where the switch can be reasonably expected to exist.
> 
> How about this?
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
> 
> Thanks,
> Severin
> 
>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>>
>>> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>>>
>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>> here (-O2 is sufficient it seems):
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>>>
>>> More thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] https://github.com/gromero/strictmath/
>>>
>>
>>
> 

From martinrb at google.com  Wed Sep 12 04:39:24 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Sep 2018 21:39:24 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
Message-ID: <CA+kOe08auNO2CcMQKqh9=8gQ2kOyyKq3fp1vSGUKdpsHcPt+5w@mail.gmail.com>

On Tue, Sep 11, 2018 at 9:04 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:

> What I can say is that I think List is the better fit here, because:
> - the result is not large

If we're talking about classpath splitting ...

At Google, we continue to struggle with classpaths that have on the
order of 10,000 elements, and the total length of the classpath arg
exceeds Linux's 128k per-arg command line limit MAX_ARG_STRLEN.

From thomas.stuefe at gmail.com  Wed Sep 12 05:20:05 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 12 Sep 2018 07:20:05 +0200
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CA+kOe0-tEvC1VDg_mZC7U5nCcu7dS7dkGLbjZatB3oXx08fNMg@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe0-tEvC1VDg_mZC7U5nCcu7dS7dkGLbjZatB3oXx08fNMg@mail.gmail.com>
Message-ID: <CAA-vtUydSKFP+vnVa4tv57Q0dny2eOgMpf0pqwGGisbhzKsy4A@mail.gmail.com>

On Wed, Sep 12, 2018 at 2:33 AM, Martin Buchholz <martinrb at google.com> wrote:
> https://sourceware.org/ml/libc-alpha/2018-09/msg00120.
> Coincidence?

Yes :) Interesting though.

From t.linkowski at gmail.com  Wed Sep 12 05:34:34 2018
From: t.linkowski at gmail.com (Tomasz Linkowski)
Date: Wed, 12 Sep 2018 07:34:34 +0200
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java
Message-ID: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>

Hello Stuart,

I'm not sure whether you're aware that IntelliJ IDEA has an automatic
inspection named "C-style array declaration":
- description:
https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/src/inspectionDescriptions/CStyleArrayDeclaration.html
- logic:
https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/InspectionGadgetsAnalysis/src/com/siyeh/ig/style/CStyleArrayDeclarationInspection.java

You can run such single inspection over the entire project as described
here:
https://www.jetbrains.com/help/idea/running-inspection-by-name.html

It will fix all such C-style array declarations for you automatically.

-- 
Regards,
Tomasz Linkowski


From: Stuart Marks <stuart.marks at oracle.com>
> To: "ullenboom at gmail.com" <ullenboom at gmail.com>
> Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Bcc:
> Date: Tue, 11 Sep 2018 13:23:41 -0700
> Subject: Re: ByteArrayOutputStream should not have a new writeBytes method
> in Java 11



2. even if, it should not be byte b[] but byte[] b


> Yeah we need to clean occurrences of this anachronistic array declaration
> from the JDK. I noticed a few others nearby. It's startling that a new
> occurrence has crept it. (Or maybe not, perhaps it was done to conform to
> the nearby code.)


> Any volunteers to clean this up?


> An interesting exercise would be to write a detector for this declaration
> style.


> s'marks

From Michael.Rasmussen at roguewave.com  Wed Sep 12 05:36:37 2018
From: Michael.Rasmussen at roguewave.com (Michael Rasmussen)
Date: Wed, 12 Sep 2018 05:36:37 +0000
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
 <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>,
 <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
Message-ID: <BL0PR02MB491406DDE941CB9252E3077CE01B0@BL0PR02MB4914.namprd02.prod.outlook.com>

> I noticed a few others nearby. It's startling that a new occurrence has crept it.
At least I haven't seen it on return types, like: public byte toArray() [] { ... }

> An interesting exercise would be to write a detector for this declaration style.
Can a language syntax/feature be deprecated to produce a warning in javac?
Perhaps this one should.

/Michael

From thomas.stuefe at gmail.com  Wed Sep 12 07:04:04 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 12 Sep 2018 09:04:04 +0200
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CANghgrRH8qiHU-2+AFgT4ktcudegGHnVnGXXbkG+7gyU=Nf1pQ@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CANghgrRH8qiHU-2+AFgT4ktcudegGHnVnGXXbkG+7gyU=Nf1pQ@mail.gmail.com>
Message-ID: <CAA-vtUzHhTO5fffD6JT3sjx+kZ54J6=ZXt-qCGWMgtjR_Y-EQQ@mail.gmail.com>

Hi David,

On Tue, Sep 11, 2018 at 8:29 PM, David Lloyd <david.lloyd at redhat.com> wrote:
> I think this is a cool idea.

Thanks. I think I did not come up with it though, I think the
technique was known already.

> Do you have any performance numbers?

Sure:

small program, just spawning off /bin/true a 1000 times, measured on
my t450s running Ubuntu 16.4:

Number open files:   <none>           1000       100000

openjdk8:                  305ms             1.5s        115s
sapjvm8:                   721ms              2.3s       142s

factor                         2.4                   1.53        1.23

So, it starts off with factor 2.3, but penalty diminishes with the
number of open files. This comparison is a imprecise however since we
compare different JVMs with completely different Runtime.exec()
implementations. We do more checks in our JVM, which may mean more
syscalls per fork().

..Thomas

> On Tue, Sep 11, 2018 at 12:52 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>> Hi all,
>>
>> I wanted to gauge opinions on the following issue:
>>
>> Runtime.exec, on Linux, uses vfork(2) by default. It gives us better
>> performance compared with fork() and robustness in constrained memory
>> situations.
>>
>> But as we know vfork() can be dangerous if used incorrectly. In the
>> child process before exec'ing, we live in the memory of the parent
>> process. If we are not very careful we can influence or crash the
>> parent process.
>>
>> According to POSIX pretty much the only thing the child process is
>> allowed to do after vfork(2) is to exec(3) immediately; if that fails,
>> you must call _exit(2).
>>
>> http://pubs.opengroup.org/onlinepubs/009604599/functions/vfork.html
>>
>> However, in the openjdk we do a number of things beyond that:
>>
>> - stdin,out,err pipe handling business
>> - closing all file descriptors
>> - we change the working directory
>> - we may actually modify errno manually
>> - in case exec fails, we communicate the error back to the parent using pipe.
>>
>> This involves calling a number of libc functions beyond exec(), namely
>> read, close, dup2, opendir/readdir, write, chdir... It also needs a
>> bit of stack, since we assemble path names.
>>
>> --
>>
>> I was curious whether there were any real issues, so I tested (on
>> Ubuntu 16.4) and found:
>>
>> 1) A crash - any crash - in the child process before exec() will kill
>> the parent jvm dead. Weirdly enough, we do not even enter our error
>> handling, but seem to die instantly with the default "Segmentation
>> Fault".
>>
>> 2) Signals received by the child process before exec() influence the
>> parent process. For example:
>>  - SIGINT set to the child ends both parent and child, immediately
>>  - SIGABRT aborts both child and parent
>>  - any error signal sent to the child lead to the behavior described at (1)
>>
>> 3) A stack overflow in the child before exec() also kills the parent.
>> Unsurprising, since guard page hit -> segfault -> see (1).
>>
>> 4) more amusing, setting errno in the child before exec() changes the
>> errno in the parent process. propagates to the parent process.
>> But since errno is thread local and the thread in the parent process
>> is waiting in vfork() and will, upon return, not look at errno (after
>> all, vfork succeeded) this causes no trouble.
>>
>> There may be more issues, but these were the ones I tested.
>>
>> In all cases I counter-tested with fork() instead of vfork() and as
>> expected  with fork() the parent process stays unaffected as it should
>> be.
>>
>> -------------
>>
>> Whether you think these issues are worth solving is an open question.
>>
>> All these cases may happen in the wild (well, apart from
>> crash-by-programming-error if one assumes the program to be really bug
>> free) albeit with a very small probability. But once these bugs occur,
>> they can be very difficult to analyse. So fixing this may be
>> worthwhile.
>>
>> At SAP, we opted for robustness, so we changed the Runtime.exec()
>> implementation to deal with vfork() issues. Basically, we employ the
>> exec-twice technique:
>>
>> - in the child, after the vfork(), we immediately exec() into a little
>> bootstrap binary ("forkhelper").
>> - Now we are safe in the sense that we do not share memory with the
>> parent process anymore
>> - Then, parent process communicates with the child via pipes and gives
>> it all information needed to do the "real" exec: environ, current dir,
>> arguments... .
>> - Now the child exec's a second time, this time into the real target binary.
>>
>> The point of this technique is that we minimize the window in the
>> child between vfork and the first exec. In fact, we are now fully
>> POSIX compliant. This solves the described pathological cases.
>>
>> It has some other advantages too, e.g. allowing for better error
>> handling and tracing in the Runtime.exec() area. Performance-wise it
>> depends: we exec twice, so we pay twice. However, since the parent
>> continues execution after the first exec, it spends less time waiting
>> on the child process, which can make a difference if there are many
>> file descriptors open.
>>
>> ---
>>
>> Checking opinions here. Do you think we are okay with our current
>> implementation or would a change as described above be welcome in the
>> OpenJDK too?
>>
>> Thanks, and Best Regards, Thomas
>
>
>
> --
> - DML

From amy.lu at oracle.com  Wed Sep 12 07:22:01 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 12 Sep 2018 15:22:01 +0800
Subject: [12] RFR of JDK-8209772: Refactor shell test
 java/util/ServiceLoader/basic/basic.sh to java
Message-ID: <77269474-6f15-0490-610d-de8adb1c169f@oracle.com>

test/jdk/java/util/ServiceLoader/basic/basic.sh

Please review this patch to refactor above shell script test to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8209772
webrev: http://cr.openjdk.java.net/~amlu/8209772/webrev.00/

Thanks,
Amy

From sgehwolf at redhat.com  Wed Sep 12 07:48:08 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 12 Sep 2018 09:48:08 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
Message-ID: <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>

Hi David,

On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> Hi Severin,
> 
> Sorry I'm a bit confused now.
> 
> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was 
> HIGH. But now it will be LOW due to:
> 
>    45 ifneq ($(FDLIBM_CFLAGS), )
>    46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> 
> as those platforms will use gcc/clang with support for -ffp-contract and 
> so FDLIBM_CFLAGS will not be empty.
> 
> ??

Correct. That was done based on Andrew Haley's comment here:
http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023160.html

I've done some measurements with -O2 and -O3. -O2 is sufficient for a
2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
sin/cos on ppc64le.

Since the difference between them were not huge, I've used -O2, a.k.a
LOW. See also:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/

To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
== -O2 on gcc arches. Does that clear things up?

FWIW, I'm happy to change it back to HIGH if there are concerns. See
also Gustavo's reply here for some more data points:
http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023193.html

Thanks,
Severin

> David
> 
> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > Thanks for the review!
> > 
> > On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
> > > Hello Severin,
> > > 
> > > Even if using the macro, I still think you need to add a condition on
> > > the compiler types where the switch can be reasonably expected to exist.
> > 
> > How about this?
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
> > 
> > Thanks,
> > Severin
> > 
> > > On 2018-09-11 05:02, Severin Gehwolf wrote:
> > > > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> > > > > I see. I was not aware of that issue, but we clearly need to file a bug
> > > > > for it and fix it. In this case I think it's fine to us the macro however.
> > > > 
> > > > OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
> > > > 
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
> > > > 
> > > > Micro-benchmark results from running [1] for x86_64 and ppc64le are
> > > > here (-O2 is sufficient it seems):
> > > > 
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> > > > 
> > > > More thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > [1] https://github.com/gromero/strictmath/
> > > > 
> > > 
> > > 


From sgehwolf at redhat.com  Wed Sep 12 07:53:32 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 12 Sep 2018 09:53:32 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <2fe884fc-843b-ee59-101d-8148a1407408@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <2fe884fc-843b-ee59-101d-8148a1407408@oracle.com>
Message-ID: <da24a066519e57c37be3a08a8abc9924673aa3f8.camel@redhat.com>

On Tue, 2018-09-11 at 10:30 -0700, Erik Joelsson wrote:
> Looks good, thanks!

Thanks for the review, Erik.

We've ran JCK 11 on this patch which passed on our end. I'll wait a few
more days whether there are objections and then push it.

Thanks,
Severin

> /Erik
> 
> 
> On 2018-09-11 09:14, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > Thanks for the review!
> > 
> > On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
> > > Hello Severin,
> > > 
> > > Even if using the macro, I still think you need to add a
> > > condition on
> > > the compiler types where the switch can be reasonably expected to
> > > exist.
> > 
> > How about this?
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
> > 
> > Thanks,
> > Severin
> > 
> > > On 2018-09-11 05:02, Severin Gehwolf wrote:
> > > > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> > > > > I see. I was not aware of that issue, but we clearly need to
> > > > > file a bug
> > > > > for it and fix it. In this case I think it's fine to us the
> > > > > macro however.
> > > > 
> > > > OK. Update webrev, which now uses
> > > > FLAGS_COMPILER_CHECK_ARGUMENTS.
> > > > 
> > > > 
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
> > > > 
> > > > Micro-benchmark results from running [1] for x86_64 and ppc64le
> > > > are
> > > > here (-O2 is sufficient it seems):
> > > > 
> > > > 
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> > > > 
> > > > More thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > [1] https://github.com/gromero/strictmath/
> > > > 
> 
> 


From david.holmes at oracle.com  Wed Sep 12 07:58:23 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Sep 2018 17:58:23 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
Message-ID: <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>

Hi Severin,

On 12/09/2018 5:48 PM, Severin Gehwolf wrote:
> Hi David,
> 
> On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> Sorry I'm a bit confused now.
>>
>> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
>> HIGH. But now it will be LOW due to:
>>
>>     45 ifneq ($(FDLIBM_CFLAGS), )
>>     46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
>>
>> as those platforms will use gcc/clang with support for -ffp-contract and
>> so FDLIBM_CFLAGS will not be empty.
>>
>> ??
> 
> Correct. That was done based on Andrew Haley's comment here:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023160.html
> 
> I've done some measurements with -O2 and -O3. -O2 is sufficient for a
> 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
> the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
> sin/cos on ppc64le.
> 
> Since the difference between them were not huge, I've used -O2, a.k.a
> LOW. See also:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> 
> To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
> == -O2 on gcc arches. Does that clear things up?

Yes that explains the missing -O2 - thanks.

But I don't understand why the optimization setting is being tied to the 
availability of the -ffp-contract flag?

Thanks,
David

> FWIW, I'm happy to change it back to HIGH if there are concerns. See
> also Gustavo's reply here for some more data points:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023193.html
> 
> Thanks,
> Severin
> 
>> David
>>
>> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
>>> Hi Erik,
>>>
>>> Thanks for the review!
>>>
>>> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>>>> Hello Severin,
>>>>
>>>> Even if using the macro, I still think you need to add a condition on
>>>> the compiler types where the switch can be reasonably expected to exist.
>>>
>>> How about this?
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
>>>
>>> Thanks,
>>> Severin
>>>
>>>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>>>>
>>>>> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>>>
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>>>>>
>>>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>>>> here (-O2 is sufficient it seems):
>>>>>
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>>>>>
>>>>> More thoughts?
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>>> [1] https://github.com/gromero/strictmath/
>>>>>
>>>>
>>>>
> 

From sgehwolf at redhat.com  Wed Sep 12 08:16:02 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 12 Sep 2018 10:16:02 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
Message-ID: <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>

On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> But I don't understand why the optimization setting is being tied to the 
> availability of the -ffp-contract flag?

In configure we perform a check for gcc or clang whether that flag is
supported. If it is, it would be non-empty exactly having -ffp-contract 
as value. It could be another set of flags for other arches if somebody
wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
madd -fno-strict-aliasing" for ppc64:
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63

We need support for that flag (or a set of flags) when we optimize
fdlibm since otherwise we would lose precision. If the flag is empty
we'd not optimize as we can't guarantee precision. That's why we tie
optimization to the availability of that flag. The expectation is for
this flag to be available on gcc/clang arches only at this point. Does
that make sense?

Thanks,
Severin


From matthias.baesken at sap.com  Wed Sep 12 09:27:15 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 12 Sep 2018 09:27:15 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
 <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <bc465382ae334570878668cc2e5612d3@sap.com>
 <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com>
Message-ID: <VI1PR02MB43845B9549743C27568F6991931B0@VI1PR02MB4384.eurprd02.prod.outlook.com>

Hello I changed it to jar , also added  some minor adjustments suggested by Christoph .

http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.12/


Regards, Matthias


> -----Original Message-----
> From: Sean Mullan <sean.mullan at oracle.com>
> Sent: Dienstag, 11. September 2018 20:44
> To: Langer, Christoph <christoph.langer at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Weijun Wang <weijun.wang at oracle.com>
> Cc: 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 9/11/18 8:14 AM, Langer, Christoph wrote:
> > Hi,
> >
> > first of all, I suggest to use "jarDetails" instead of "jarPath" as category
> name. Because with this contribution we add the notion of jar file plus line of
> manifest to Exceptions occurring when parsing jar manifests. And if there
> were further Exception details to be added in the area of jar files, they could
> go under a category "jarDetails" as well. Would you agree? Then, in
> Manifest.java, the field "jarPathInExceptionText" could be renamed to
> "detailedExceptions".
> 
> Or just "jar" would be my preference. I don't like "jarPath" as that
> sounds too much like a file pathname to me, which we have now removed.
> 
> --Sean

From magnus.ihse.bursie at oracle.com  Wed Sep 12 10:19:59 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 12 Sep 2018 12:19:59 +0200
Subject: [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
Message-ID: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>



On 2018-09-10 23:34, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209167
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/

Some comments:
In make/copy/Copy-java.base.gmk:
+ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)

The findstring construct is hard to read and only needed when we test 
more than one OS. Please rewrite as a single ifeq test for aix.

In GensrcCLDR.gmk:
I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
generate it, there's just a dependency..?

The removal of the duplicate "common", that seems like a separate bug fix?

/Magnus

>
> This fix is to remove the hand crafted map file (lib/tzmappings) on 
> Windows, which maps Windows time zones to Java's tzid. It is now 
> dynamically generated at the build time, using CLDR's data file 
> (windowsZones.xml)
>
> Naoto


From magnus.ihse.bursie at oracle.com  Wed Sep 12 10:32:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 12 Sep 2018 12:32:14 +0200
Subject: [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
Message-ID: <fd707ac4-5de1-64bb-bdd1-9baaa10c14ba@oracle.com>


On 2018-09-12 12:19, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-10 23:34, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/

Oh, and there's a typo in CLDRConverter.java: " Note: the entries are 
alphabetically soreted, *except* the "world" region".

/Magnus

From magnus.ihse.bursie at oracle.com  Wed Sep 12 10:46:30 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 12 Sep 2018 12:46:30 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
Message-ID: <19891d2a-393c-fa31-7b5b-278cb4f90533@oracle.com>

On 2018-09-11 18:14, Severin Gehwolf wrote:
> Hi Erik,
>
> Thanks for the review!
>
> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> Even if using the macro, I still think you need to add a condition on
>> the compiler types where the switch can be reasonably expected to exist.
> How about this?
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
Looks good to me, too.

Thanks for keeping the spirit high despite the high number of respins of 
the patch!

/Magnus

>
> Thanks,
> Severin
>
>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>>>
>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>> here (-O2 is sufficient it seems):
>>>
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>>>
>>> More thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] https://github.com/gromero/strictmath/
>>>
>>


From christoph.langer at sap.com  Wed Sep 12 11:34:15 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 12 Sep 2018 11:34:15 +0000
Subject: [RFR] 8205525 : Improve exception messages during manifest
 parsing of jar archives
In-Reply-To: <VI1PR02MB43845B9549743C27568F6991931B0@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <0cee5b67a5d1476d8318837b770de382@sap.com>
 <b197f112ef474462aa4fc6773676a636@sap.com>
 <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com>
 <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m>
 <c43e39e4-1653-ebdb-9368-e131b5bf7150@oracle.com>
 <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com>
 <VI1PR02MB4384D8E8C74BAD1A5EC7301D93050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <a9fbf7d556464d1ca6d5d08d21e634ff@sap.com>
 <VI1PR02MB4384D94F50A71D2D9D6AFDB593050@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com>
 <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com>
 <b5b0967f76e5460fbee2564ec1560179@sap.com>
 <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com>
 <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com>
 <VI1PR02MB4384106FCFF70707AED1958793040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <B1B1AA5E-2E80-4863-BE3C-46C9A2B0C300@oracle.com>
 <VI1PR02MB43840DB3B1E2BC81C364C6C193040@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <bc465382ae334570878668cc2e5612d3@sap.com>
 <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com>
 <VI1PR02MB43845B9549743C27568F6991931B0@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <1f624224baf540d193d053af4f650e96@sap.com>

Looks good to me.

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Mittwoch, 12. September 2018 11:27
> To: Sean Mullan <sean.mullan at oracle.com>; Langer, Christoph
> <christoph.langer at sap.com>; Weijun Wang <weijun.wang at oracle.com>
> Cc: 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
> 
> Hello I changed it to jar , also added  some minor adjustments suggested by
> Christoph .
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.12/
> 
> 
> Regards, Matthias
> 
> 
> > -----Original Message-----
> > From: Sean Mullan <sean.mullan at oracle.com>
> > Sent: Dienstag, 11. September 2018 20:44
> > To: Langer, Christoph <christoph.langer at sap.com>; Baesken, Matthias
> > <matthias.baesken at sap.com>; Weijun Wang <weijun.wang at oracle.com>
> > Cc: 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 9/11/18 8:14 AM, Langer, Christoph wrote:
> > > Hi,
> > >
> > > first of all, I suggest to use "jarDetails" instead of "jarPath" as category
> > name. Because with this contribution we add the notion of jar file plus line
> of
> > manifest to Exceptions occurring when parsing jar manifests. And if there
> > were further Exception details to be added in the area of jar files, they
> could
> > go under a category "jarDetails" as well. Would you agree? Then, in
> > Manifest.java, the field "jarPathInExceptionText" could be renamed to
> > "detailedExceptions".
> >
> > Or just "jar" would be my preference. I don't like "jarPath" as that
> > sounds too much like a file pathname to me, which we have now removed.
> >
> > --Sean


From christoph.langer at sap.com  Wed Sep 12 11:47:30 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 12 Sep 2018 11:47:30 +0000
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
Message-ID: <942b134f36034614b226ddbf252aaa6d@sap.com>

Hi Thomas,

I like the full patch ?? +1

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Thomas St?fe
> Sent: Dienstag, 11. September 2018 19:27
> To: Java Core Libs <core-libs-dev at openjdk.java.net>
> Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
> FD_CLOEXEC instead of close()
> 
> Hi all,
> 
> May I please have reviews for this small fix:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
> 
> patch (full): http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-
> FD_CLOEXEC-instead-of-close/webrev.00/webrev/
> patch (minimal alternative):
> http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-
> instead-of-close/webrev.minimal/webrev/
> 
> See also prior discussion:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> September/055173.html
> 
> Submit tests ran with full patch successfully through.
> 
> ---
> 
> Background:
> 
> After fork()/vfork() and before exec(), the child process needs to
> close all inherited file descriptors apart from the stdin/out/err pipe
> ends. We do this by iterating thru all file descriptors in
> /proc/<pid>/fd or whatever the equivalent is on that platform. This is
> done using opendir(), readdir().
> 
> We then close all these file descriptors using close().
> 
> The problem with that technique is that we may accidentally close the
> file descriptor opendir() is using internally to read the directory
> content of /proc/<pid>/fd, thereby sawing off the branch we are
> sitting on. The coding does some magic to attempt to prevent this:
> 
> <quote>
> 86    /* We're trying to close all file descriptors, but opendir() might
> 87     * itself be implemented using a file descriptor, and we certainly
> 88     * don't want to close that while it's in use.  We assume that if
> 89     * opendir() is implemented using a file descriptor, then it uses
> 90     * the lowest numbered file descriptor, just like open().  So we
> 91     * close a couple explicitly.  */
> 92
> 93    close(from_fd);          /* for possible use by opendir() */
> 94    close(from_fd + 1);      /* another one for good luck */
> 
> ...
> 108    while ((dirp = readdir64(dp)) != NULL) {
> 109        int fd;
> 110        if (isAsciiDigit(dirp->d_name[0]) &&
> 111            (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd +
> 2)Improve "close all filedescriptors" coding.
> 112            close(fd);
> 113    }
> 
> </quote>
> 
> This workaround can be removed if, instead of outright closing the
> file descriptor in the loop, we were to set the file descriptor to
> FD_CLOEXEC. Closing all descriptors would be defered to the actual
> exec() call some milliseconds later.
> 
> ----
> 
> The patch changes the close() call to fcntl(FD_CLOEXEC). This removes
> the need for the workaround as described.
> 
> In addition to that, the full version of the patch also adds error
> handling to the readdir() loop.
> 
> But note that this exposes us to a behavioral change should we run
> into a readdir() error:
> 
> - currently, we would leave the remaining file descriptors quietly
> unclosed. This usually would have no effect, but in rare cases may
> lead to difficult-to-analyze errors when child processes accidentally
> disturb parent process IO.
> 
> - With this patch, we will fail if readdir fails. However, we do not
> just yet fail the Runtime.exec() call, but enter a fallback code
> section here:
> 
> 364     /* close everything */
> 365     if (closeDescriptors() == 0) { /* failed,  close the old way */
> 366         int max_fd = (int)sysconf(_SC_OPEN_MAX);
> 367         int fd;
> 368         for (fd = FAIL_FILENO + 1; fd < max_fd; fd++)
> 369             if (close(fd) == -1 && errno != EBADF)
> 370                 goto WhyCantJohnnyExec;
> 371     }
> 
> I am not convinced this is a good fallback. _SC_OPEN_MAX depends on
> ulimit -Hn and may be high. On my Ubuntu 16.4 box, default value after
> installation is 1048576. When we hit this fallback code, it takes
> almost a full second to spawn a single child process. In fork
> intensive scenarios this can get pretty bad.
> 
> What do you think?
> 
> Thanks & Best Regards,
> 
> Thomas

From thomas.stuefe at gmail.com  Wed Sep 12 11:52:31 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 12 Sep 2018 13:52:31 +0200
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <942b134f36034614b226ddbf252aaa6d@sap.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
 <942b134f36034614b226ddbf252aaa6d@sap.com>
Message-ID: <CAA-vtUwD5F69xqiPkUZC3+ghorcdMU7E3wATOH-3BXivTaGeWA@mail.gmail.com>

Thank you Christoph :)

On Wed, Sep 12, 2018 at 1:47 PM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi Thomas,
>
> I like the full patch ?? +1
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>> Of Thomas St?fe
>> Sent: Dienstag, 11. September 2018 19:27
>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>> Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
>> FD_CLOEXEC instead of close()
>>
>> Hi all,
>>
>> May I please have reviews for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
>>
>> patch (full): http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-
>> FD_CLOEXEC-instead-of-close/webrev.00/webrev/
>> patch (minimal alternative):
>> http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-
>> instead-of-close/webrev.minimal/webrev/
>>
>> See also prior discussion:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
>> September/055173.html
>>
>> Submit tests ran with full patch successfully through.
>>
>> ---
>>
>> Background:
>>
>> After fork()/vfork() and before exec(), the child process needs to
>> close all inherited file descriptors apart from the stdin/out/err pipe
>> ends. We do this by iterating thru all file descriptors in
>> /proc/<pid>/fd or whatever the equivalent is on that platform. This is
>> done using opendir(), readdir().
>>
>> We then close all these file descriptors using close().
>>
>> The problem with that technique is that we may accidentally close the
>> file descriptor opendir() is using internally to read the directory
>> content of /proc/<pid>/fd, thereby sawing off the branch we are
>> sitting on. The coding does some magic to attempt to prevent this:
>>
>> <quote>
>> 86    /* We're trying to close all file descriptors, but opendir() might
>> 87     * itself be implemented using a file descriptor, and we certainly
>> 88     * don't want to close that while it's in use.  We assume that if
>> 89     * opendir() is implemented using a file descriptor, then it uses
>> 90     * the lowest numbered file descriptor, just like open().  So we
>> 91     * close a couple explicitly.  */
>> 92
>> 93    close(from_fd);          /* for possible use by opendir() */
>> 94    close(from_fd + 1);      /* another one for good luck */
>>
>> ...
>> 108    while ((dirp = readdir64(dp)) != NULL) {
>> 109        int fd;
>> 110        if (isAsciiDigit(dirp->d_name[0]) &&
>> 111            (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd +
>> 2)Improve "close all filedescriptors" coding.
>> 112            close(fd);
>> 113    }
>>
>> </quote>
>>
>> This workaround can be removed if, instead of outright closing the
>> file descriptor in the loop, we were to set the file descriptor to
>> FD_CLOEXEC. Closing all descriptors would be defered to the actual
>> exec() call some milliseconds later.
>>
>> ----
>>
>> The patch changes the close() call to fcntl(FD_CLOEXEC). This removes
>> the need for the workaround as described.
>>
>> In addition to that, the full version of the patch also adds error
>> handling to the readdir() loop.
>>
>> But note that this exposes us to a behavioral change should we run
>> into a readdir() error:
>>
>> - currently, we would leave the remaining file descriptors quietly
>> unclosed. This usually would have no effect, but in rare cases may
>> lead to difficult-to-analyze errors when child processes accidentally
>> disturb parent process IO.
>>
>> - With this patch, we will fail if readdir fails. However, we do not
>> just yet fail the Runtime.exec() call, but enter a fallback code
>> section here:
>>
>> 364     /* close everything */
>> 365     if (closeDescriptors() == 0) { /* failed,  close the old way */
>> 366         int max_fd = (int)sysconf(_SC_OPEN_MAX);
>> 367         int fd;
>> 368         for (fd = FAIL_FILENO + 1; fd < max_fd; fd++)
>> 369             if (close(fd) == -1 && errno != EBADF)
>> 370                 goto WhyCantJohnnyExec;
>> 371     }
>>
>> I am not convinced this is a good fallback. _SC_OPEN_MAX depends on
>> ulimit -Hn and may be high. On my Ubuntu 16.4 box, default value after
>> installation is 1048576. When we hit this fallback code, it takes
>> almost a full second to spawn a single child process. In fork
>> intensive scenarios this can get pretty bad.
>>
>> What do you think?
>>
>> Thanks & Best Regards,
>>
>> Thomas

From martinrb at google.com  Wed Sep 12 12:30:48 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 05:30:48 -0700
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
Message-ID: <CA+kOe08L+g8PuWhUa+LKYP9HO=i_=S3ZEUzZiUaPtCNt8754uw@mail.gmail.com>

The reference
from_fd + 2
needs updating since it assumes two file descriptors have already been closed?

On Tue, Sep 11, 2018 at 10:27 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi all,
>
> May I please have reviews for this small fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
>
> patch (full): http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.00/webrev/
> patch (minimal alternative):
> http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.minimal/webrev/
>
> See also prior discussion:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055173.html
>
> Submit tests ran with full patch successfully through.
>
> ---
>
> Background:
>
> After fork()/vfork() and before exec(), the child process needs to
> close all inherited file descriptors apart from the stdin/out/err pipe
> ends. We do this by iterating thru all file descriptors in
> /proc/<pid>/fd or whatever the equivalent is on that platform. This is
> done using opendir(), readdir().
>
> We then close all these file descriptors using close().
>
> The problem with that technique is that we may accidentally close the
> file descriptor opendir() is using internally to read the directory
> content of /proc/<pid>/fd, thereby sawing off the branch we are
> sitting on. The coding does some magic to attempt to prevent this:
>
> <quote>
> 86    /* We're trying to close all file descriptors, but opendir() might
> 87     * itself be implemented using a file descriptor, and we certainly
> 88     * don't want to close that while it's in use.  We assume that if
> 89     * opendir() is implemented using a file descriptor, then it uses
> 90     * the lowest numbered file descriptor, just like open().  So we
> 91     * close a couple explicitly.  */
> 92
> 93    close(from_fd);          /* for possible use by opendir() */
> 94    close(from_fd + 1);      /* another one for good luck */
>
> ...
> 108    while ((dirp = readdir64(dp)) != NULL) {
> 109        int fd;
> 110        if (isAsciiDigit(dirp->d_name[0]) &&
> 111            (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd +
> 2)Improve "close all filedescriptors" coding.
> 112            close(fd);
> 113    }
>
> </quote>
>
> This workaround can be removed if, instead of outright closing the
> file descriptor in the loop, we were to set the file descriptor to
> FD_CLOEXEC. Closing all descriptors would be defered to the actual
> exec() call some milliseconds later.
>
> ----
>
> The patch changes the close() call to fcntl(FD_CLOEXEC). This removes
> the need for the workaround as described.
>
> In addition to that, the full version of the patch also adds error
> handling to the readdir() loop.
>
> But note that this exposes us to a behavioral change should we run
> into a readdir() error:
>
> - currently, we would leave the remaining file descriptors quietly
> unclosed. This usually would have no effect, but in rare cases may
> lead to difficult-to-analyze errors when child processes accidentally
> disturb parent process IO.
>
> - With this patch, we will fail if readdir fails. However, we do not
> just yet fail the Runtime.exec() call, but enter a fallback code
> section here:
>
> 364     /* close everything */
> 365     if (closeDescriptors() == 0) { /* failed,  close the old way */
> 366         int max_fd = (int)sysconf(_SC_OPEN_MAX);
> 367         int fd;
> 368         for (fd = FAIL_FILENO + 1; fd < max_fd; fd++)
> 369             if (close(fd) == -1 && errno != EBADF)
> 370                 goto WhyCantJohnnyExec;
> 371     }
>
> I am not convinced this is a good fallback. _SC_OPEN_MAX depends on
> ulimit -Hn and may be high. On my Ubuntu 16.4 box, default value after
> installation is 1048576. When we hit this fallback code, it takes
> almost a full second to spawn a single child process. In fork
> intensive scenarios this can get pretty bad.
>
> What do you think?
>
> Thanks & Best Regards,
>
> Thomas

From thomas.stuefe at gmail.com  Wed Sep 12 12:46:54 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 12 Sep 2018 14:46:54 +0200
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CA+kOe08L+g8PuWhUa+LKYP9HO=i_=S3ZEUzZiUaPtCNt8754uw@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
 <CA+kOe08L+g8PuWhUa+LKYP9HO=i_=S3ZEUzZiUaPtCNt8754uw@mail.gmail.com>
Message-ID: <CAA-vtUy4LJ7jFLw0N8UygFDKjnBF6dvekAmpV8HCgCF7Xx9QfA@mail.gmail.com>

On Wed, Sep 12, 2018 at 2:30 PM, Martin Buchholz <martinrb at google.com> wrote:
> The reference
> from_fd + 2
> needs updating since it assumes two file descriptors have already been closed?

Good catch, I will fix that.

Btw, should I retry the readdir() on EINTR?

..Thomas

>
> On Tue, Sep 11, 2018 at 10:27 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Hi all,
>>
>> May I please have reviews for this small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210549
>>
>> patch (full): http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.00/webrev/
>> patch (minimal alternative):
>> http://cr.openjdk.java.net/~stuefe/webrevs/8210549-Use-FD_CLOEXEC-instead-of-close/webrev.minimal/webrev/
>>
>> See also prior discussion:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055173.html
>>
>> Submit tests ran with full patch successfully through.
>>
>> ---
>>
>> Background:
>>
>> After fork()/vfork() and before exec(), the child process needs to
>> close all inherited file descriptors apart from the stdin/out/err pipe
>> ends. We do this by iterating thru all file descriptors in
>> /proc/<pid>/fd or whatever the equivalent is on that platform. This is
>> done using opendir(), readdir().
>>
>> We then close all these file descriptors using close().
>>
>> The problem with that technique is that we may accidentally close the
>> file descriptor opendir() is using internally to read the directory
>> content of /proc/<pid>/fd, thereby sawing off the branch we are
>> sitting on. The coding does some magic to attempt to prevent this:
>>
>> <quote>
>> 86    /* We're trying to close all file descriptors, but opendir() might
>> 87     * itself be implemented using a file descriptor, and we certainly
>> 88     * don't want to close that while it's in use.  We assume that if
>> 89     * opendir() is implemented using a file descriptor, then it uses
>> 90     * the lowest numbered file descriptor, just like open().  So we
>> 91     * close a couple explicitly.  */
>> 92
>> 93    close(from_fd);          /* for possible use by opendir() */
>> 94    close(from_fd + 1);      /* another one for good luck */
>>
>> ...
>> 108    while ((dirp = readdir64(dp)) != NULL) {
>> 109        int fd;
>> 110        if (isAsciiDigit(dirp->d_name[0]) &&
>> 111            (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd +
>> 2)Improve "close all filedescriptors" coding.
>> 112            close(fd);
>> 113    }
>>
>> </quote>
>>
>> This workaround can be removed if, instead of outright closing the
>> file descriptor in the loop, we were to set the file descriptor to
>> FD_CLOEXEC. Closing all descriptors would be defered to the actual
>> exec() call some milliseconds later.
>>
>> ----
>>
>> The patch changes the close() call to fcntl(FD_CLOEXEC). This removes
>> the need for the workaround as described.
>>
>> In addition to that, the full version of the patch also adds error
>> handling to the readdir() loop.
>>
>> But note that this exposes us to a behavioral change should we run
>> into a readdir() error:
>>
>> - currently, we would leave the remaining file descriptors quietly
>> unclosed. This usually would have no effect, but in rare cases may
>> lead to difficult-to-analyze errors when child processes accidentally
>> disturb parent process IO.
>>
>> - With this patch, we will fail if readdir fails. However, we do not
>> just yet fail the Runtime.exec() call, but enter a fallback code
>> section here:
>>
>> 364     /* close everything */
>> 365     if (closeDescriptors() == 0) { /* failed,  close the old way */
>> 366         int max_fd = (int)sysconf(_SC_OPEN_MAX);
>> 367         int fd;
>> 368         for (fd = FAIL_FILENO + 1; fd < max_fd; fd++)
>> 369             if (close(fd) == -1 && errno != EBADF)
>> 370                 goto WhyCantJohnnyExec;
>> 371     }
>>
>> I am not convinced this is a good fallback. _SC_OPEN_MAX depends on
>> ulimit -Hn and may be high. On my Ubuntu 16.4 box, default value after
>> installation is 1048576. When we hit this fallback code, it takes
>> almost a full second to spawn a single child process. In fork
>> intensive scenarios this can get pretty bad.
>>
>> What do you think?
>>
>> Thanks & Best Regards,
>>
>> Thomas

From martinrb at google.com  Wed Sep 12 12:59:09 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 05:59:09 -0700
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CAA-vtUy4LJ7jFLw0N8UygFDKjnBF6dvekAmpV8HCgCF7Xx9QfA@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
 <CA+kOe08L+g8PuWhUa+LKYP9HO=i_=S3ZEUzZiUaPtCNt8754uw@mail.gmail.com>
 <CAA-vtUy4LJ7jFLw0N8UygFDKjnBF6dvekAmpV8HCgCF7Xx9QfA@mail.gmail.com>
Message-ID: <CA+kOe0_r5FhNPWMFun2bCORkqyShK2NwDyPyZA0EaVjV6ddHyw@mail.gmail.com>

On Wed, Sep 12, 2018 at 5:46 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> On Wed, Sep 12, 2018 at 2:30 PM, Martin Buchholz <martinrb at google.com> wrote:

> Btw, should I retry the readdir() on EINTR?

If I read
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
correctly, then readdir should never fail with EINTR

From david.lloyd at redhat.com  Wed Sep 12 13:08:53 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 12 Sep 2018 08:08:53 -0500
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CAA-vtUzHhTO5fffD6JT3sjx+kZ54J6=ZXt-qCGWMgtjR_Y-EQQ@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CANghgrRH8qiHU-2+AFgT4ktcudegGHnVnGXXbkG+7gyU=Nf1pQ@mail.gmail.com>
 <CAA-vtUzHhTO5fffD6JT3sjx+kZ54J6=ZXt-qCGWMgtjR_Y-EQQ@mail.gmail.com>
Message-ID: <CANghgrTTR+BJmLgzymaEfREjZybbyL3D0o=rjtON60YCYp1MWA@mail.gmail.com>

On Wed, Sep 12, 2018 at 2:04 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi David,
>
> On Tue, Sep 11, 2018 at 8:29 PM, David Lloyd <david.lloyd at redhat.com> wrote:
> > I think this is a cool idea.
>
> Thanks. I think I did not come up with it though, I think the
> technique was known already.
>
> > Do you have any performance numbers?
>
> Sure:
>
> small program, just spawning off /bin/true a 1000 times, measured on
> my t450s running Ubuntu 16.4:
>
> Number open files:   <none>           1000       100000
>
> openjdk8:                  305ms             1.5s        115s
> sapjvm8:                   721ms              2.3s       142s
>
> factor                         2.4                   1.53        1.23

This doesn't seem too bad, even for a first implementation.  I wonder
if it could be improved further using e.g. shared memory to reduce
syscalls?

-- 
- DML

From martinrb at google.com  Wed Sep 12 13:17:07 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 06:17:07 -0700
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
Message-ID: <CA+kOe0_wbxUxvLp3Tmg-u8B4v3AFE4pRVkcnDYVMqxWaizVt_Q@mail.gmail.com>

In 2018, we can assume everyone has implemented FD_CLOEXEC.

Back in 1970, 20 file descriptors was enough for any program, but
today they're effectively unlimited, so futilely closing _SC_OPEN_MAX
descriptors has become unreasonable (as you say).  OTOH, there is
still no standard way of ensuring all our file descriptors are closed.
Do we need the fallback on your beloved HP-UX?  Should we simply close
the first 64k file descriptors and pray, as is traditional?

freebsd offers closefrom(2)
https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpath=freebsd-release-ports
and today we can autoconfiscate the existence of closefrom and use
that where available (BSD and Solaris?)

closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ?

I'd give this function a javadoc style docstring.

(Finding the FD_DIR directory has become rather ugly, especially the
AIX-specific code)

From gromero at linux.vnet.ibm.com  Wed Sep 12 13:29:01 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 12 Sep 2018 10:29:01 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <47e56a18-a5f7-3583-9f5e-ede471586b8e@linux.vnet.ibm.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <b737ffd4-af98-5780-60dc-8f3b4a6d0783@oracle.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <47e56a18-a5f7-3583-9f5e-ede471586b8e@linux.vnet.ibm.com>
Message-ID: <d9226a6d-80da-d755-b241-7ac1c0c22482@linux.vnet.ibm.com>

Hi Andrew,

On 09/12/2018 12:51 AM, Gustavo Romero wrote:
> 
> Maybe Andrew can enlight us.

I was not sure if 'enlight us' was the correct form here, so I did some search
and I found with horror today that 'enlighten us' can also be considered an
insult (!?).

That's really not the case here. So if it's really possible to interpret it in
a non-positive / non-cordial way I sincerely apologize for the wrong use.

I was really only asking for an advice. :)


Regards,
Gustavo


From martinrb at google.com  Wed Sep 12 14:20:13 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 07:20:13 -0700
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
Message-ID: <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>

I agree that your proposal makes the implementation more robust, so if
you are willing to implement it and it doesn't cost too much, then I
would support it.  The current implementation doesn't seem to cause
trouble in practice, or at least we don't see any bug reports.

When you benchmark with open file descriptors, try with and without
FD_CLOEXEC flag set.  Almost all fds should be created with the
FD_CLOEXEC flag set - openjdk is moving in that direction.  When there
are many open files, your implementation may be a weird sort of
optimization.

On Tue, Sep 11, 2018 at 10:51 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> The point of this technique is that we minimize the window in the
> child between vfork and the first exec. In fact, we are now fully
> POSIX compliant.

2004-POSIX compliant ... but in the mean time they removed vfork().
But vfork is critical for Google (and probably others)  due to the
momentary overcommit problem on Linux.  Or has that changed somehow?

From roger.riggs at oracle.com  Wed Sep 12 14:30:08 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 12 Sep 2018 10:30:08 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <20180911094952.979472405@eggemoggin.niobe.net>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <94A1E66C-3AD9-4EDD-9790-8000D7B40A00@oracle.com>
 <20180911094952.979472405@eggemoggin.niobe.net>
Message-ID: <52712b2d-0c27-d99d-6a61-04fdcb0ee635@oracle.com>

Hi,

My original intention was to provide minimal support for parsing a 
property value
and handling OS specific behaviors (quoting).

java.nio.file.Paths is a bit of backwater (now that Path.of was added) 
and its factories are dedicated to handling Paths.

I considered a new type representing a search path but that seemed to 
expand the scope beyond the minimum.

Search path logic is not one of the high profile functions used by lots 
of developers and there seem to be many variations on how they are used.

It is also a slippery slope since it could easily expand to add many 
useful functions
that applications already deal with themselves.

 ?- Searching the path for a particular file or directory
 ?- Supporting patterns for matching files on the path, using filters or 
glob patterns
 ?- Caching of previous lookups or directory contents
 ?- Optimizing the search path, ignoring duplicate entries, etc.

If that's the direction this should go it expands the scope quite a bit.

Thanks, Roger

On 9/11/18 12:49 PM, mark.reinhold at oracle.com wrote:
> 2018/9/11 4:50:49 -0700, chris.hegarty at oracle.com:
>>> On 11 Sep 2018, at 10:24, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> On 10/09/2018 21:55, Roger Riggs wrote:
>>>> Nope! there's quoting on Windows that gets short changed with that work around.
>>>>
>>>> Other opinions?, Suggestions?
>>> One suggestion is reduce this down to one method that returns a
>>> stream rather than a collection. It could work lazily if you
>>> want. Something like:
>>>
>>>   Stream<String> splitSearchPath(String input)
>> I agree with Alan, this seems like the lowest-order primitive.
> Agreed, but it begs a question that applies to all these alternatives:
> Why does this API belong in java.nio.file.Paths?
>
> In other words, search paths are a different abstraction from filesystem
> paths.  Should they have their own class, even if it only winds up with
> a couple of static utility methods?  java.nio.file.SearchPath?
>
>      public class SearchPath {
>          public static Stream<String> splitToStream(String searchPath);
>          public static List<Path> splitToPaths(String searchPath);
>          public static String join(Collection<String>);
>      }
>
> - Mark


From roger.riggs at oracle.com  Wed Sep 12 14:30:47 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 12 Sep 2018 10:30:47 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <169427a1-7095-d905-c6a6-c367d2fd280a@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <169427a1-7095-d905-c6a6-c367d2fd280a@oracle.com>
Message-ID: <cd3c219a-57cc-f08f-6c2c-f297c5ee2e8e@oracle.com>

Hi Stuart,

The implementation retains the previous handling of empty path elements 
for URLClassPath
in the implementation.? The spec for the new methods is explicit about 
dropping empty elements.

For a library API, it is inadvisable to support implicit context such as 
the current working directory.
I received some offline comments about proposing too many methods and
dropped the variants that supported replacing empty path elements with 
an explicit path.

Keeping the empty path elements would simplify the spec though.

Thanks, Roger


On 9/11/18 4:54 PM, Stuart Marks wrote:
> Hi Roger,
>
>> ?110????? * Returns a list of path strings parsed from a string with 
>> empty paths removed.
>
> The Unix shell and the Java launcher's -classpath processing treat an 
> empty path entry as the current working directory. (I don't know what 
> happens on Windows.) Removing empty paths thus would seem to change 
> the semantics of search paths, at least on some systems.
>
> s'marks
>
> On 9/10/18 11:16 AM, Roger Riggs wrote:
>> Please review the API and implementation of an API to parse Path 
>> strings.
>> Two methods are added to java.nio.file.Paths to parse a string using 
>> the path separator delimiter
>> and return either List<String> or List<Path>.? Empty path elements 
>> are ignored.
>>
>> For compatibility with current URLClassPath behavior the internal 
>> implementation handles
>> replacement of empty paths.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/ 
>>
>>
>> CSR:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8208208
>>
>> Thanks, Roger
>>


From david.lloyd at redhat.com  Wed Sep 12 14:33:09 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 12 Sep 2018 09:33:09 -0500
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
Message-ID: <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>

On Wed, Sep 12, 2018 at 9:21 AM Martin Buchholz <martinrb at google.com> wrote:
>
> I agree that your proposal makes the implementation more robust, so if
> you are willing to implement it and it doesn't cost too much, then I
> would support it.  The current implementation doesn't seem to cause
> trouble in practice, or at least we don't see any bug reports.
>
> When you benchmark with open file descriptors, try with and without
> FD_CLOEXEC flag set.  Almost all fds should be created with the
> FD_CLOEXEC flag set - openjdk is moving in that direction.  When there
> are many open files, your implementation may be a weird sort of
> optimization.
>
> On Tue, Sep 11, 2018 at 10:51 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> > The point of this technique is that we minimize the window in the
> > child between vfork and the first exec. In fact, we are now fully
> > POSIX compliant.
>
> 2004-POSIX compliant ... but in the mean time they removed vfork().
> But vfork is critical for Google (and probably others)  due to the
> momentary overcommit problem on Linux.  Or has that changed somehow?

If the lack of POSIX support is a problem, posix_spawn could possibly
be used instead in this case:

> The child process is created using vfork(2) instead of fork(2) when [...] file_actions is NULL and the spawn-flags element of the attributes object pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.

This would only work if the helper program is run directly though.

-- 
- DML

From christoph.langer at sap.com  Wed Sep 12 14:44:59 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 12 Sep 2018 14:44:59 +0000
Subject: Re-iterate JDK-6194856: Zip Files lose ALL ownership and permissions
 of the files
Message-ID: <4f24f30e05c54ddea749ba0c6fa19c3e@sap.com>

Hi all,

I'm currently revisiting a long standing shortcoming of the java.util.zip (and java.util.jar) implementation.

The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter...

I personally can imagine contributing the following:

First step: Enrich java.util.zip.ZipEntry with some method(s) like getUnixPermissions() and setUnixPermissions().
For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D.  Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the java.util.zip package [2].
Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header.
This seems to be the de-facto standard of the GNU zip/unzip implementation.
With that addition the the java.util.zip API, developers using it would get the ability to cope with Unix permissions.

As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting.

Isn't that something that should be done? Or, if not, why?

Thanks and best regards in advance
Christoph

[1] https://bugs.openjdk.java.net/browse/JDK-6194856
[2] http://www.info-zip.org/doc/appnote-19970311-iz.zip


From roger.riggs at oracle.com  Wed Sep 12 14:57:34 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 12 Sep 2018 10:57:34 -0400
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
 <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
Message-ID: <272d32e7-e22a-c87e-71ba-7d1dd2a0984a@oracle.com>

Hi David,

How does your proposal differ from the current posix_spawn and 
jspawnhelper MODE_POSIX_SPAWN
implementation available on Solaris and AIX?
This area is sensitive enough that it would be prudent to implement it 
as a new mode in ProcessImpl/ProcessImpl; retaining the existing options.
Changing the default could be a build option and would require extensive 
testing and a long stability period.

Regards, Roger

On 9/12/18 10:33 AM, David Lloyd wrote:
> On Wed, Sep 12, 2018 at 9:21 AM Martin Buchholz <martinrb at google.com> wrote:
>> I agree that your proposal makes the implementation more robust, so if
>> you are willing to implement it and it doesn't cost too much, then I
>> would support it.  The current implementation doesn't seem to cause
>> trouble in practice, or at least we don't see any bug reports.
>>
>> When you benchmark with open file descriptors, try with and without
>> FD_CLOEXEC flag set.  Almost all fds should be created with the
>> FD_CLOEXEC flag set - openjdk is moving in that direction.  When there
>> are many open files, your implementation may be a weird sort of
>> optimization.
>>
>> On Tue, Sep 11, 2018 at 10:51 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>>> The point of this technique is that we minimize the window in the
>>> child between vfork and the first exec. In fact, we are now fully
>>> POSIX compliant.
>> 2004-POSIX compliant ... but in the mean time they removed vfork().
>> But vfork is critical for Google (and probably others)  due to the
>> momentary overcommit problem on Linux.  Or has that changed somehow?
> If the lack of POSIX support is a problem, posix_spawn could possibly
> be used instead in this case:
>
>> The child process is created using vfork(2) instead of fork(2) when [...] file_actions is NULL and the spawn-flags element of the attributes object pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.
> This would only work if the helper program is run directly though.
>


From david.lloyd at redhat.com  Wed Sep 12 15:16:39 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 12 Sep 2018 10:16:39 -0500
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <272d32e7-e22a-c87e-71ba-7d1dd2a0984a@oracle.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
 <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
 <272d32e7-e22a-c87e-71ba-7d1dd2a0984a@oracle.com>
Message-ID: <CANghgrRHadHT8gkd5bUA8rVMM0J1NQm1sPPosfkgq5TKGX+Zsw@mail.gmail.com>

On Wed, Sep 12, 2018 at 9:58 AM Roger Riggs <roger.riggs at oracle.com> wrote:
>
> Hi David,
>
> How does your proposal differ from the current posix_spawn and
> jspawnhelper MODE_POSIX_SPAWN
> implementation available on Solaris and AIX?

Reading through the code, it ends up being pretty much identical
AFAICT; if I understand correctly, Linux would be using vfork (or its
equivalent) internally in this case.

> This area is sensitive enough that it would be prudent to implement it
> as a new mode in ProcessImpl/ProcessImpl; retaining the existing options.
> Changing the default could be a build option and would require extensive
> testing and a long stability period.

Seems worthwhile though, given vfork's now-10-year-old obsolescence.
It looks like Linux is the only platform still using vfork for
ProcessImpl in OpenJDK.

-- 
- DML

From martinrb at google.com  Wed Sep 12 15:55:55 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 08:55:55 -0700
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
 <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
Message-ID: <CA+kOe08xFEE4rfSzHkEDhHQ8x4UAThJ6Gs5q8HmHWtJ45U9BuA@mail.gmail.com>

On Wed, Sep 12, 2018 at 7:33 AM, David Lloyd <david.lloyd at redhat.com> wrote:
>> The child process is created using vfork(2) instead of fork(2) when [...] file_actions is NULL and the spawn-flags element of the attributes object pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.

Yes, the posix_spawn man page says that, but
https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/spawni.c#L36
says:

/* The Linux implementation of posix_spawn{p} uses the clone syscall directly
with CLONE_VM and CLONE_VFORK flags and an allocated stack. The new stack
and start function solves most the vfork limitation (possible parent
clobber due stack spilling).

From martinrb at google.com  Wed Sep 12 16:01:33 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 09:01:33 -0700
Subject: Runtime.exec : vfork() concerns and a fix proposal
In-Reply-To: <CANghgrRHadHT8gkd5bUA8rVMM0J1NQm1sPPosfkgq5TKGX+Zsw@mail.gmail.com>
References: <CAA-vtUwtv+pdOehxN9yHR4DC5-i1hrey1pc1z5mYMdqeKTKe6g@mail.gmail.com>
 <CA+kOe08Ae+0Q==4ePh3aZiG3U_VF60Di8uizThHWAPe6h-ZmBw@mail.gmail.com>
 <CANghgrR4u6KRSzYjjY1n3Xmv_Ha=Gzsg=m33doKfoqeCBpGvHw@mail.gmail.com>
 <272d32e7-e22a-c87e-71ba-7d1dd2a0984a@oracle.com>
 <CANghgrRHadHT8gkd5bUA8rVMM0J1NQm1sPPosfkgq5TKGX+Zsw@mail.gmail.com>
Message-ID: <CA+kOe0_ufcNr0uAtw=9=TM4aOaaUq6j2W62GCzXkRLuWgfP7NQ@mail.gmail.com>

On Wed, Sep 12, 2018 at 8:16 AM, David Lloyd <david.lloyd at redhat.com> wrote:

> Seems worthwhile though, given vfork's now-10-year-old obsolescence.
> It looks like Linux is the only platform still using vfork for
> ProcessImpl in OpenJDK.

I'm fine with switching to posix_spawn on Linux as long as we don't
reintroduce the memory overcommit problem, which would be a
deal-breaker.  But glibc posix_spawn will use either vfork or clone
with CLONE_VFORK, so we should be OK.

From erik.joelsson at oracle.com  Wed Sep 12 16:08:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Sep 2018 09:08:52 -0700
Subject: [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
Message-ID: <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>

On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-10 23:34, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>
> Some comments:
> In make/copy/Copy-java.base.gmk:
> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>
> The findstring construct is hard to read and only needed when we test 
> more than one OS. Please rewrite as a single ifeq test for aix.
>
> In GensrcCLDR.gmk:
> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
> generate it, there's just a dependency..?
>
It's generated by the same rule as the other file. This is the easiest 
workaround for two files generated from the same rule. It sort of works 
(for clean builds and if the input is chagned), but won't handle all 
cases where one file is removed externally and the other is not. I 
suggested this construct to Naoto. Perhaps a comment explaining this 
would be good.
> The removal of the duplicate "common", that seems like a separate bug 
> fix?
>
It does indeed. Before this fix, the wildcards must have returned empty.

/Erik
> /Magnus
>
>>
>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>> Windows, which maps Windows time zones to Java's tzid. It is now 
>> dynamically generated at the build time, using CLDR's data file 
>> (windowsZones.xml)
>>
>> Naoto
>


From martinrb at google.com  Wed Sep 12 16:18:43 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Sep 2018 09:18:43 -0700
Subject: Re-iterate JDK-6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <4f24f30e05c54ddea749ba0c6fa19c3e@sap.com>
References: <4f24f30e05c54ddea749ba0c6fa19c3e@sap.com>
Message-ID: <CA+kOe0_FdA9-XJLZKLqVHX3PeY+LtB0EiF=zRKYGTSQmDFt+pw@mail.gmail.com>

In principle I support making system specific extensions to the ZIP
spec more supported, as other zip implementations do.  There is long
standing tension between Java trying to be highly portable and
providing access to the data you need.  It's already the case that
some implementation bits are not exposed but the zip implementation
handles it "magically" under the covers, e.g. IIRC the utf-8 bit.
There is also tension between ZipEntry as just a mutable struct and a
read-only interface to an existing zip file.  Performance of zip
implementations is critical so one would like to do lazy lookup.
Coming up with a good design for j.u.zip evolution is hard.

On Wed, Sep 12, 2018 at 7:44 AM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi all,
>
> I'm currently revisiting a long standing shortcoming of the java.util.zip (and java.util.jar) implementation.
>
> The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter...
>
> I personally can imagine contributing the following:
>
> First step: Enrich java.util.zip.ZipEntry with some method(s) like getUnixPermissions() and setUnixPermissions().
> For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D.  Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the java.util.zip package [2].
> Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header.
> This seems to be the de-facto standard of the GNU zip/unzip implementation.
> With that addition the the java.util.zip API, developers using it would get the ability to cope with Unix permissions.
>
> As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting.
>
> Isn't that something that should be done? Or, if not, why?
>
> Thanks and best regards in advance
> Christoph
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6194856
> [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip
>

From peter.levart at gmail.com  Wed Sep 12 16:31:22 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 12 Sep 2018 18:31:22 +0200
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <cd3c219a-57cc-f08f-6c2c-f297c5ee2e8e@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <169427a1-7095-d905-c6a6-c367d2fd280a@oracle.com>
 <cd3c219a-57cc-f08f-6c2c-f297c5ee2e8e@oracle.com>
Message-ID: <ee05688b-da99-dcd8-8667-0bef60182db2@gmail.com>



On 09/12/2018 04:30 PM, Roger Riggs wrote:
> Hi Stuart,
>
> The implementation retains the previous handling of empty path 
> elements for URLClassPath
> in the implementation.? The spec for the new methods is explicit about 
> dropping empty elements.
>
> For a library API, it is inadvisable to support implicit context such 
> as the current working directory.
> I received some offline comments about proposing too many methods and
> dropped the variants that supported replacing empty path elements with 
> an explicit path.
>
> Keeping the empty path elements would simplify the spec though.

...and it's easy to .filter() them out if the parsing method returns 
Stream<String>...

Regards, Peter

>
> Thanks, Roger
>
>
> On 9/11/18 4:54 PM, Stuart Marks wrote:
>> Hi Roger,
>>
>>> ?110 * Returns a list of path strings parsed from a string with 
>>> empty paths removed.
>>
>> The Unix shell and the Java launcher's -classpath processing treat an 
>> empty path entry as the current working directory. (I don't know what 
>> happens on Windows.) Removing empty paths thus would seem to change 
>> the semantics of search paths, at least on some systems.
>>
>> s'marks


From anthonyv.be at outlook.com  Wed Sep 12 17:29:38 2018
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Wed, 12 Sep 2018 17:29:38 +0000
Subject: JDK-8124977: deadlock between engineers? (cmdline encoding challenges
 on Windows)
Message-ID: <DB5PR07MB13978FACBEC0D75F530C5062E81B0@DB5PR07MB1397.eurprd07.prod.outlook.com>

Hi

What is the status of this issue [1]? It addresses some long-standing issues with Java's Unicode support on Windows and was contributed by a team of Microsoft engineers. However, it seems to have gone dormant right before the finish line, and I can't really figure out who's waiting for whom at this point.

A little reconstruction from what I could find:
In January 2015, Martin Sawicki made the initial proposal to address the cmdline encoding challenges on Windows [2]
>From June to September, there were ongoing discussions [3][4][5][6]
In November, this was shortly picked up again by the Oracle engineers [7]
In January 2016, after a ping by a Microsoft engineer, the discussions restarted [8]
In February 2016, the patch seemed nearly ready for integration, with an Oracle engineer asking whom to mention as contributors etc. [9]
Since then, I was unable to find any messages related to this issue

(Personally, I would love to see this issue progress, in order to be able to associate Java programs with file extensions on Windows. This is currently problematic, since a file containing Unicode characters will not get passed correctly as an argument to the Java program)

Kind regards,
Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8124977
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
[3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
[4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
[5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
[6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
[7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
[8] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
[9] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html

From naoto.sato at oracle.com  Wed Sep 12 17:33:44 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 12 Sep 2018 10:33:44 -0700
Subject: [12]: RFR: 8209167: Use CLDR's time zone mappings for Windows
In-Reply-To: <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
Message-ID: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>

Hi Magnus, Erik,

Thank you for your comments. I updated the webrev according to your 
suggestions:

http://cr.openjdk.java.net/~naoto/8209167/webrev.02/

As to the duplicated "common" in the dependency, yes that's a separate 
issue. Since it's obvious, I included the fix with this changeset (it 
was actually described as a comment in the jira issue).

Naoto

On 9/12/18 9:08 AM, Erik Joelsson wrote:
> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-09-10 23:34, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>
>> Some comments:
>> In make/copy/Copy-java.base.gmk:
>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>
>> The findstring construct is hard to read and only needed when we test 
>> more than one OS. Please rewrite as a single ifeq test for aix.
>>
>> In GensrcCLDR.gmk:
>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>> generate it, there's just a dependency..?
>>
> It's generated by the same rule as the other file. This is the easiest 
> workaround for two files generated from the same rule. It sort of works 
> (for clean builds and if the input is chagned), but won't handle all 
> cases where one file is removed externally and the other is not. I 
> suggested this construct to Naoto. Perhaps a comment explaining this 
> would be good.
>> The removal of the duplicate "common", that seems like a separate bug 
>> fix?
>>
> It does indeed. Before this fix, the wildcards must have returned empty.
> 
> /Erik
>> /Magnus
>>
>>>
>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>> dynamically generated at the build time, using CLDR's data file 
>>> (windowsZones.xml)
>>>
>>> Naoto
>>
> 

From xueming.shen at oracle.com  Wed Sep 12 17:33:41 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 12 Sep 2018 10:33:41 -0700
Subject: Re-iterate JDK-6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <CA+kOe0_FdA9-XJLZKLqVHX3PeY+LtB0EiF=zRKYGTSQmDFt+pw@mail.gmail.com>
References: <4f24f30e05c54ddea749ba0c6fa19c3e@sap.com>
 <CA+kOe0_FdA9-XJLZKLqVHX3PeY+LtB0EiF=zRKYGTSQmDFt+pw@mail.gmail.com>
Message-ID: <5B994DF5.6050903@oracle.com>


It's hard to get the ZipEntry API right to perfectly handle these 
platform specific
"file system attributes" especially given the potential performance and 
security
concern.

I would assume zipfs might be a better place to handle this if "really" 
desired,
in which already has the base to handle "file attributes". We can have a 
zipfs
based jar/zip somewhere to take advantage of its file system nature. For
example, start from "open/test/jdk/jdk/nio/zipfs/Demo.java" :-)

-Sherman


On 9/12/18, 9:18 AM, Martin Buchholz wrote:
> In principle I support making system specific extensions to the ZIP
> spec more supported, as other zip implementations do.  There is long
> standing tension between Java trying to be highly portable and
> providing access to the data you need.  It's already the case that
> some implementation bits are not exposed but the zip implementation
> handles it "magically" under the covers, e.g. IIRC the utf-8 bit.
> There is also tension between ZipEntry as just a mutable struct and a
> read-only interface to an existing zip file.  Performance of zip
> implementations is critical so one would like to do lazy lookup.
> Coming up with a good design for j.u.zip evolution is hard.
>
> On Wed, Sep 12, 2018 at 7:44 AM, Langer, Christoph
> <christoph.langer at sap.com>  wrote:
>> Hi all,
>>
>> I'm currently revisiting a long standing shortcoming of the java.util.zip (and java.util.jar) implementation.
>>
>> The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter...
>>
>> I personally can imagine contributing the following:
>>
>> First step: Enrich java.util.zip.ZipEntry with some method(s) like getUnixPermissions() and setUnixPermissions().
>> For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D.  Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the java.util.zip package [2].
>> Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header.
>> This seems to be the de-facto standard of the GNU zip/unzip implementation.
>> With that addition the the java.util.zip API, developers using it would get the ability to cope with Unix permissions.
>>
>> As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting.
>>
>> Isn't that something that should be done? Or, if not, why?
>>
>> Thanks and best regards in advance
>> Christoph
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6194856
>> [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip
>>


From erik.joelsson at oracle.com  Wed Sep 12 17:34:59 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Sep 2018 10:34:59 -0700
Subject: [12]: RFR: 8209167: Use CLDR's time zone mappings for Windows
In-Reply-To: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
 <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
Message-ID: <f73ea10e-74cf-3d4a-0760-deafe9fef400@oracle.com>

Looks good.

/Erik


On 2018-09-12 10:33, naoto.sato at oracle.com wrote:
> Hi Magnus, Erik,
>
> Thank you for your comments. I updated the webrev according to your 
> suggestions:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
>
> As to the duplicated "common" in the dependency, yes that's a separate 
> issue. Since it's obvious, I included the fix with this changeset (it 
> was actually described as a comment in the jira issue).
>
> Naoto
>
> On 9/12/18 9:08 AM, Erik Joelsson wrote:
>> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-09-10 23:34, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>>
>>> Some comments:
>>> In make/copy/Copy-java.base.gmk:
>>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>>
>>> The findstring construct is hard to read and only needed when we 
>>> test more than one OS. Please rewrite as a single ifeq test for aix.
>>>
>>> In GensrcCLDR.gmk:
>>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>>> generate it, there's just a dependency..?
>>>
>> It's generated by the same rule as the other file. This is the 
>> easiest workaround for two files generated from the same rule. It 
>> sort of works (for clean builds and if the input is chagned), but 
>> won't handle all cases where one file is removed externally and the 
>> other is not. I suggested this construct to Naoto. Perhaps a comment 
>> explaining this would be good.
>>> The removal of the duplicate "common", that seems like a separate 
>>> bug fix?
>>>
>> It does indeed. Before this fix, the wildcards must have returned empty.
>>
>> /Erik
>>> /Magnus
>>>
>>>>
>>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>>> dynamically generated at the build time, using CLDR's data file 
>>>> (windowsZones.xml)
>>>>
>>>> Naoto
>>>
>>


From jonathan.gibbons at oracle.com  Wed Sep 12 17:55:02 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 12 Sep 2018 10:55:02 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <ee05688b-da99-dcd8-8667-0bef60182db2@gmail.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <169427a1-7095-d905-c6a6-c367d2fd280a@oracle.com>
 <cd3c219a-57cc-f08f-6c2c-f297c5ee2e8e@oracle.com>
 <ee05688b-da99-dcd8-8667-0bef60182db2@gmail.com>
Message-ID: <620868ab-880e-f304-c706-c3791222c4a1@oracle.com>



On 9/12/18 9:31 AM, Peter Levart wrote:
>
>
> On 09/12/2018 04:30 PM, Roger Riggs wrote:
>> Hi Stuart,
>>
>> The implementation retains the previous handling of empty path 
>> elements for URLClassPath
>> in the implementation.? The spec for the new methods is explicit 
>> about dropping empty elements.
>>
>> For a library API, it is inadvisable to support implicit context such 
>> as the current working directory.
>> I received some offline comments about proposing too many methods and
>> dropped the variants that supported replacing empty path elements 
>> with an explicit path.
>>
>> Keeping the empty path elements would simplify the spec though.
>
> ...and it's easy to .filter() them out if the parsing method returns 
> Stream<String>...
or .map() them to some default value, such as the current working directory.

-- Jon
>
> Regards, Peter
>
>>
>> Thanks, Roger
>>
>>
>> On 9/11/18 4:54 PM, Stuart Marks wrote:
>>> Hi Roger,
>>>
>>>> ?110 * Returns a list of path strings parsed from a string with 
>>>> empty paths removed.
>>>
>>> The Unix shell and the Java launcher's -classpath processing treat 
>>> an empty path entry as the current working directory. (I don't know 
>>> what happens on Windows.) Removing empty paths thus would seem to 
>>> change the semantics of search paths, at least on some systems.
>>>
>>> s'marks
>


From huizhe.wang at oracle.com  Wed Sep 12 18:11:05 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 12 Sep 2018 11:11:05 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
Message-ID: <5B9956B9.104@oracle.com>

Hi,

Please review a patch for a situation where a surrogate pair is at the 
edge of a buffer. What the existing impl did was to report it as an 
error. This patch fixes it by caching the high surrogate and prints it 
out along with the low surrogate. Similar issue exists also in the CDATA 
section and is fixed in this patch. The CDATA impl had a couple of bugs 
where an indent could be written inside the CDATA and an unicode 
character written in between two CDATA sections. Both are fixed in this 
patch.

JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/

Thanks,
Joe



From hohensee at amazon.com  Wed Sep 12 18:25:54 2018
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 12 Sep 2018 18:25:54 +0000
Subject: SSL session cache default maximum number of entries
In-Reply-To: <f46628d8-6f4e-ea03-99a9-cbcf456f7145@oracle.com>
References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
 <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>
 <f46628d8-6f4e-ea03-99a9-cbcf456f7145@oracle.com>
Message-ID: <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com>

Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom.

Paul

?On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.mullan at oracle.com> wrote:

    Hi Paul,
    
    Thank you for bringing this issue to our attention. While we agree that 
    this does indeed seem like an issue that should be addressed, it is 
    quite late in the JDK 11 schedule, and it does not appear to be a new 
    issue introduced in JDK 11. We will be investigating this offline and 
    will get back to you as soon as we can with more details. Offhand, I 
    think that we would be able to change the default in an update release.
    
    Also, you are probably already be aware of this, but you can use the 
    SSLSessionContext.setSessionCacheSize() API as well as the 
    "javax.net.ssl.sessionCacheSize" system property to customize the cache 
    size.
    
    --Sean
    
    On 9/11/18 12:02 PM, Sean Mullan wrote:
    > cross-posting to security-dev since this is related to SSL/TLS.
    > 
    > On 9/11/18 11:41 AM, Hohensee, Paul wrote:
    >> The default value for the maximum number of entries in the SSL session 
    >> cache (which is a SoftReference cache) is infinite, and the entry 
    >> timeout is 24 hours. With larger heaps, we?re running into situations 
    >> where the cache ends up with several million entries when the 24 hours 
    >> are up. They?re then all invalidated at the same time, resulting in 
    >> multi-minute pauses (effectively service failures). We?ve experimented 
    >> with using 10k as the default maximum number of entries with good 
    >> results (i.e., no latency increases due to sessions falling out of the 
    >> cache). It?s late and a long shot for JDK11: we?d love to see it 
    >> changed there because 11 is an LTS release and this is, at least 
    >> nominally, a behavior change which might not be acceptable in 11u. 
    >> What do people think?
    >>
    >> Thanks,
    >>
    >> Paul
    >>
    


From stuart.marks at oracle.com  Wed Sep 12 21:01:03 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 12 Sep 2018 14:01:03 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java
In-Reply-To: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
References: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
Message-ID: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>

Cool, I didn't know that IntelliJ IDEA has such an inspection, but I'm not 
surprised.

Perhaps a volunteer can run this inspection over parts of the JDK code base and 
see what comes up, and possibly propose some patches. :-)

s'marks


On 9/11/18 10:34 PM, Tomasz Linkowski wrote:
> Hello Stuart,
>
> I'm not sure whether you're aware that IntelliJ IDEA has an automatic 
> inspection named "C-style array declaration":
> - description: 
> https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/src/inspectionDescriptions/CStyleArrayDeclaration.html
> - logic: 
> https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/InspectionGadgetsAnalysis/src/com/siyeh/ig/style/CStyleArrayDeclarationInspection.java
>
> You can run such single inspection over the entire project as described here:
> https://www.jetbrains.com/help/idea/running-inspection-by-name.html
>
> It will fix all such C-style array declarations for you automatically.
>
> -- 
> Regards,
> Tomasz Linkowski
>
>
>     From:?Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>>
>     To:?"ullenboom at gmail.com <mailto:ullenboom at gmail.com>"
>     <ullenboom at gmail.com <mailto:ullenboom at gmail.com>>
>     Cc:?"core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at openjdk.java.net>" <core-libs-dev at openjdk.java.net
>     <mailto:core-libs-dev at openjdk.java.net>>
>     Bcc:
>     Date:?Tue, 11 Sep 2018 13:23:41 -0700
>     Subject:?Re: ByteArrayOutputStream should not have a new writeBytes method
>     in Java 11 
>
>     2. even if, it should not be byte b[] but byte[] b 
>
>
>     Yeah we need to clean occurrences of this anachronistic array declaration
>     from the JDK. I noticed a few others nearby. It's startling that a new
>     occurrence has crept it. (Or maybe not, perhaps it was done to conform to
>     the nearby code.) 
>
>
>     Any volunteers to clean this up? 
>
>
>     An interesting exercise would be to write a detector for this declaration
>     style. 
>
>
>     s'marks
>


From mark.reinhold at oracle.com  Wed Sep 12 21:16:00 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 12 Sep 2018 14:16:00 -0700
Subject: RFR 8210670 (S): Accept double-dash VM-name options at launch time
Message-ID: <20180912141600.365290746@eggemoggin.niobe.net>

To make this trivial enhancement I first had to fix some broken tests,
so there are two issues and two webrevs here.

8210669: Some launcher tests assume a pre-JDK 9 run-time image layout

  Two launcher tests, ExecutionEnvironment.java and Test7029048.java (in
  test/jdk/tools/launcher), still assume the old image layout in which a
  HotSpot shared library (libjava.so) is found in $JDK/lib/$ARCH/$VMTYPE
  on Linux and Solaris.  The intermediate $ARCH directory was removed in
  JDK 9, as part of JEP 220 (Modular Run-Time Images) [1].  Since that
  time these tests have been succeeding anyway, because they don?t fail
  when the requested VM is not found.

  The tests should be fixed to fail when the requested VM is not found,
  and to look for VM shared libraries in the proper location.

  JBS: https://bugs.openjdk.java.net/browse/JDK-8210669
  Webrev: http://cr.openjdk.java.net/~mr/rev/8210669/

8210670: Accept double-dash VM-name options at launch time

  Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance
  the Java launcher so that `--server` is accepted to select the server VM,
  in addition to `-server`, and likewise for any other VMs listed in the
  $JDK/lib/jvm.cfg file.

  JBS: https://bugs.openjdk.java.net/browse/JDK-8210670
  Webrev: http://cr.openjdk.java.net/~mr/rev/8210670/

Passes tier1 tests; tier2-3 in progress.

Thanks,
- Mark


[1] http://openjdk.java.net/jeps/220
[2] http://openjdk.java.net/jeps/293

From stuart.marks at oracle.com  Wed Sep 12 21:24:21 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 12 Sep 2018 14:24:21 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java 11
In-Reply-To: <BL0PR02MB491406DDE941CB9252E3077CE01B0@BL0PR02MB4914.namprd02.prod.outlook.com>
References: <CAP0_N2EsQgMfZusGfLPmO9379XHdN-_Zf3a+fnHHfYuMC9aC5g@mail.gmail.com>
 <BL0PR02MB4914ECAB053504E374D5A7E5E0040@BL0PR02MB4914.namprd02.prod.outlook.com>
 <fe43709f-9cbf-19ee-c26e-d0bea703e2ae@oracle.com>
 <BL0PR02MB491406DDE941CB9252E3077CE01B0@BL0PR02MB4914.namprd02.prod.outlook.com>
Message-ID: <832e9e7b-3324-d38c-394c-a126b95abce4@oracle.com>



On 9/11/18 10:36 PM, Michael Rasmussen wrote:
> Can a language syntax/feature be deprecated to produce a warning in javac?
> Perhaps this one should.

We haven't reached the point of formally deprecating language features, but 
certain features like this one (and others) are certainly frowned upon by 
various style guides and reviewers. So, informally deprecated I guess.

I'd think the next step would be to have javac issue a lint warning.

Filed:

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

s'marks

From mark.reinhold at oracle.com  Wed Sep 12 22:08:58 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 12 Sep 2018 15:08:58 -0700
Subject: RFR 8210670 (S): Accept double-dash VM-name options at launch time
In-Reply-To: <20180912141600.365290746@eggemoggin.niobe.net>
References: <20180912141600.365290746@eggemoggin.niobe.net>
Message-ID: <20180912150858.590303733@eggemoggin.niobe.net>

2018/9/12 14:16:00 -0700, mark.reinhold at oracle.com:
> ...
> 
> 8210670: Accept double-dash VM-name options at launch time
> 
>   Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance
>   the Java launcher so that `--server` is accepted to select the server VM,
>   in addition to `-server`, and likewise for any other VMs listed in the
>   $JDK/lib/jvm.cfg file.
> 
>   JBS: https://bugs.openjdk.java.net/browse/JDK-8210670
>   Webrev: http://cr.openjdk.java.net/~mr/rev/8210670/
> 
> Passes tier1 tests; tier2-3 in progress.

Addendum: Joe reminded me that this change should have a CSR, so here it
is: https://bugs.openjdk.java.net/browse/JDK-8210682 .  A review of that
too would be appreciated.

I?ve also revised the code for this change, and hence the webrev, to
show the double-dash VM-name options in the `java --help` output.

- Mark

From david.holmes at oracle.com  Wed Sep 12 22:31:51 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Sep 2018 08:31:51 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
 <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
Message-ID: <bfb6743e-7657-ab9f-8596-08f2abb02e5e@oracle.com>

On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
> On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
>> But I don't understand why the optimization setting is being tied to the
>> availability of the -ffp-contract flag?
> 
> In configure we perform a check for gcc or clang whether that flag is
> supported. If it is, it would be non-empty exactly having -ffp-contract
> as value. It could be another set of flags for other arches if somebody
> wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
> madd -fno-strict-aliasing" for ppc64:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63
> 
> We need support for that flag (or a set of flags) when we optimize
> fdlibm since otherwise we would lose precision. If the flag is empty
> we'd not optimize as we can't guarantee precision. That's why we tie
> optimization to the availability of that flag. The expectation is for
> this flag to be available on gcc/clang arches only at this point. Does
> that make sense?

Yes that makes sense - thanks. I didn't quite glean that from the comment:

   42 # If FDLIBM_CFLAGS is non-empty we know that we can optimize
   43 # fdlibm by adding those extra C flags. Currently GCC,
   44 # and clang only.
   45 ifneq ($(FDLIBM_CFLAGS), )
   46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW

But now I can read it and understand.

Thanks,
David

> Thanks,
> Severin
> 

From calvin.cheung at oracle.com  Wed Sep 12 23:16:06 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Wed, 12 Sep 2018 16:16:06 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize()
 function to handle long path on windows
In-Reply-To: <5B9706BA.4080409@oracle.com>
References: <5B96BB03.3070503@oracle.com> <5B9706BA.4080409@oracle.com>
Message-ID: <5B999E36.90600@oracle.com>

Hi Sherman,

Thanks for your review.
Please refer to my reply below...

On 9/10/18, 5:05 PM, Xueming Shen wrote:
> On 9/10/18, 11:42 AM, Calvin Cheung wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>>
>> Please review this change for handling long path specified in the 
>> -Xbootclasspath/a on windows.
>>
>> Highlight of changes:
>> - canonicalize_md.c
>>     it makes use of the unicode version of canonicalize 
>> (wcanonicalize) if the original path is >= MAX_PATH.
> So we are converting mb->wc->mb in wcanonicalize (when > max_path), 
> and then feed the
> resulting path into ZFILE_Open, in which we again do mb->wc-> + prefix 
> -> CreateFileW(...)?
That's the minimal change I could come up with. Let me know if you have 
other suggestions.
>
> Maybe it's time to consider a "wchar" interface between vm and libraries.
Good idea. I think it should be done in a separate RFE.
> Maybe it's fine here given we
> are only do this for > max_path case?
This was done so that this change has no impact on the <= MAX_PATH case.
>
> Alan, now reading the win version canonicalize(...), remind me what's 
> the real purpose of doing
> FindFirstFile/FindClose() here? the API appears to suggest it is used 
> to find the first match if there
> is/are wildcards but we actually have checked/rejected the wildcards 
> at the very beginning ? To
> get the "real name" for case?
>
>>
>> - zip_util.c
>>     it uses the unicode version of CreateFile (CreateFileW) if the 
>> original path is >= MAX_PATH.
>>
>> - io_util_md.c
>>     Since zip_util.c (libzip) calls the getPrefixed() function in 
>> canonicalize_md.c (libjava), the getPrefixed() function needs to be 
>> exported.
>
> I kinda remembered that we once wanted to avoid export an variant of 
> winFileHandleOpen() from
> libjava to libzip ... in this case the alternative is to simply 
> copy/paste the getPrefix into libzip ...
> but I don't remember the exact concern back then.
I also thought of copy/paste the getPrefix function into libzip.
After looking at the lib/CoreLibraries.gmk, I think libzip already has a 
dependency on libjava:
$(eval $(call SetupJdkLibrary, BUILD_LIBZIP, \
     NAME := zip, \
     OPTIMIZATION := LOW, \
     EXCLUDES := $(LIBZIP_EXCLUDES), \
     CFLAGS := $(CFLAGS_JDKLIB) \
         $(LIBZ_CFLAGS), \
     CFLAGS_unix := $(BUILD_LIBZIP_MMAP) -UDEBUG, \
     LDFLAGS := $(LDFLAGS_JDKLIB) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
))

I've done tier1,2,3 testing and didn't see any new failures.
I can do higher tier testing if needed.

thanks,
Calvin

p.s. I didn't see this email until Ioi forwarded it to me since I wasn't 
in the core-libs-dev alias. (I've subscribed to the alias this morning.)

>
> -Sherman
>
>
>
>>
>>
>> - java_md.h
>>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It 
>> is because the the current usage of the canonicalize() function from 
>> vm code is to preallocate the output buffer as follows:
>>             char* canonical_path = 
>> NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>>             if (!get_canonical_path(path, canonical_path, 
>> JVM_MAXPATHLEN)) {
>>     Also the unix version of canonicalize() function has the 
>> following check:
>>             int
>>            canonicalize(char *original, char *resolved, int len)
>>            {
>>                if (len < PATH_MAX) {
>>                errno = EINVAL;
>>                return -1;
>>            }
>>    So dynamically allocating the output buffer requires more work 
>> beyond the scope of this change.
>>
>> - LongBCP.java
>>     added a scenario to the test - a long path to a jar file in 
>> -Xbootclasspath/a.
>>
>> Testing: tier-[1,2,3].
>>
>> thanks,
>> Calvin
>

From lance.andersen at oracle.com  Wed Sep 12 23:25:36 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 12 Sep 2018 19:25:36 -0400
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <5B9956B9.104@oracle.com>
References: <5B9956B9.104@oracle.com>
Message-ID: <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>

Hi Joe,

The change  seems reasonable

> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a patch for a situation where a surrogate pair is at the edge of a buffer. What the existing impl did was to report it as an error. This patch fixes it by caching the high surrogate and prints it out along with the low surrogate. Similar issue exists also in the CDATA section and is fixed in this patch. The CDATA impl had a couple of bugs where an indent could be written inside the CDATA and an unicode character written in between two CDATA sections. Both are fixed in this patch.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
> 
> 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 david.holmes at oracle.com  Thu Sep 13 01:00:57 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Sep 2018 11:00:57 +1000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <bfb6743e-7657-ab9f-8596-08f2abb02e5e@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
 <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
 <bfb6743e-7657-ab9f-8596-08f2abb02e5e@oracle.com>
Message-ID: <5dc2351a-1432-ff66-fa74-7712726408ec@oracle.com>

Correction ...

On 13/09/2018 8:31 AM, David Holmes wrote:
> On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
>> On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
>>> But I don't understand why the optimization setting is being tied to the
>>> availability of the -ffp-contract flag?
>>
>> In configure we perform a check for gcc or clang whether that flag is
>> supported. If it is, it would be non-empty exactly having -ffp-contract
>> as value. It could be another set of flags for other arches if somebody
>> wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
>> madd -fno-strict-aliasing" for ppc64:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63 
>>
>>
>> We need support for that flag (or a set of flags) when we optimize
>> fdlibm since otherwise we would lose precision. If the flag is empty
>> we'd not optimize as we can't guarantee precision. That's why we tie
>> optimization to the availability of that flag. The expectation is for
>> this flag to be available on gcc/clang arches only at this point. Does
>> that make sense?
> 
> Yes that makes sense - thanks. I didn't quite glean that from the comment:
> 
>  ? 42 # If FDLIBM_CFLAGS is non-empty we know that we can optimize
>  ? 43 # fdlibm by adding those extra C flags. Currently GCC,

I think this should say "when adding" not "by adding".

Thanks,
David

>  ? 44 # and clang only.
>  ? 45 ifneq ($(FDLIBM_CFLAGS), )
>  ? 46?? BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> 
> But now I can read it and understand.
> 
> Thanks,
> David
> 
>> Thanks,
>> Severin
>>

From joe.darcy at oracle.com  Thu Sep 13 01:44:08 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 12 Sep 2018 18:44:08 -0700
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
 <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
Message-ID: <3d510e25-464d-bf27-bd65-dddbf24024ce@oracle.com>

Hello,

On 9/12/2018 1:16 AM, Severin Gehwolf wrote:
> On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
>> But I don't understand why the optimization setting is being tied to the
>> availability of the -ffp-contract flag?
> In configure we perform a check for gcc or clang whether that flag is
> supported. If it is, it would be non-empty exactly having -ffp-contract
> as value. It could be another set of flags for other arches if somebody
> wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
> madd -fno-strict-aliasing" for ppc64:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63
>
> We need support for that flag (or a set of flags) when we optimize
> fdlibm since otherwise we would lose precision. If the flag is empty
> we'd not optimize as we can't guarantee precision. That's why we tie
> optimization to the availability of that flag. The expectation is for
> this flag to be available on gcc/clang arches only at this point. Does
> that make sense?
>
>

To condense a potentially long discussion, while the IEEE 754 standard 
has long specified particular results for arithmetic operations (+, -, 
*, /, etc.) on particular floating-point values, languages and their 
compilers often do not provide a reliable mapping of language constructs 
to IEEE 754 operations.

The Java language and JVM are distinctive in this sense because a 
reliable mapping of language-level operation to particular IEEE 754 
operation is mandated by the JLS. (I will leave aside a complicated but 
largely irrelevant discussion of non-strictfp floating-point.)

The C language standards I've looked at do not provide as reliably a 
mapping of floating-point operations as the JLS does. In particular, the 
C standards generally allow a fused multiply add to be used replace a 
pair of add and multiply instructions in an expression like (a * b + c). 
The -ffp-contract=off gcc compiler setting disables this and related 
transformations. (The Sun Studio compilers provide detailed 
configuration options for the sets of floating-point transformations 
that are allowed.)

The specification for StrictMath requires the fdlibm algorithms and the 
fdlibm algorithms rely on the semantics of the floating-point operations 
as written in the source and also rely on some way of doing a bit-wise 
conversion between an integral type and double. The latter is 
accomplished by interpreting the 64-bits of a double as comprising a 
two-element array of 32-bit ints. These idioms often don't work under 
the default C compiler options, leading to the long-standing need to 
have a separate set of compiler options for FDLIBM. A safe, if slow, set 
of options is to fully disable optimization for FDLIBM. That is not 
necessary if sufficient control over the floating-point and aliasing 
semantics is possible via the C compiler options.

In the fullness of time, when (if?) I finish porting the FDLIBM code to 
Java, these sorts of concerns will no longer apply due to the more 
reliably mapping of source expressions in Java to IEEE 754 
floating-point operations.

HTH,

-Joe

From xueming.shen at oracle.com  Thu Sep 13 01:52:03 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 12 Sep 2018 18:52:03 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize() function
 to handle long path on windows
In-Reply-To: <5B999E36.90600@oracle.com>
References: <5B96BB03.3070503@oracle.com> <5B9706BA.4080409@oracle.com>
 <5B999E36.90600@oracle.com>
Message-ID: <5B99C2C3.3000302@oracle.com>

Hi Calvin,

I believe I was thinking of keeping the "getPrefixed" as an 
implementation details and
instead exporting a "A" version of winFileHandleOpen() back then. But I 
don't have a
strong opinion on this one, so your approach looks fine.

No, I don't have a better idea for now to avoid those mb->ws->mb as long 
as the canonicalize()
and zip_open() are two separate invocations. But since they are only for 
 > max_path path. I'm
fine with it.

Yes, I think it's time to consider to migrate from interpreting the 
char* as "mb chars" to probably
"utf8 chars" (take a step back, I don't think it's easy to do to 
actually a wchar interface) for windows
platform, but that would be a separate and big rfes.

nit:

130             fname,              /* Ascii char path name */

the comment probably should be "path name in mb char", or ANSI charset.

Thanks,

-Sherman

On 9/12/18, 4:16 PM, Calvin Cheung wrote:
> Hi Sherman,
>
> Thanks for your review.
> Please refer to my reply below...
>
> On 9/10/18, 5:05 PM, Xueming Shen wrote:
>> On 9/10/18, 11:42 AM, Calvin Cheung wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>>>
>>> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>>>
>>> Please review this change for handling long path specified in the 
>>> -Xbootclasspath/a on windows.
>>>
>>> Highlight of changes:
>>> - canonicalize_md.c
>>>     it makes use of the unicode version of canonicalize 
>>> (wcanonicalize) if the original path is >= MAX_PATH.
>> So we are converting mb->wc->mb in wcanonicalize (when > max_path), 
>> and then feed the
>> resulting path into ZFILE_Open, in which we again do mb->wc-> + 
>> prefix -> CreateFileW(...)?
> That's the minimal change I could come up with. Let me know if you 
> have other suggestions.
>>
>> Maybe it's time to consider a "wchar" interface between vm and 
>> libraries.
> Good idea. I think it should be done in a separate RFE.
>> Maybe it's fine here given we
>> are only do this for > max_path case?
> This was done so that this change has no impact on the <= MAX_PATH case.
>>
>> Alan, now reading the win version canonicalize(...), remind me what's 
>> the real purpose of doing
>> FindFirstFile/FindClose() here? the API appears to suggest it is used 
>> to find the first match if there
>> is/are wildcards but we actually have checked/rejected the wildcards 
>> at the very beginning ? To
>> get the "real name" for case?
>>
>>>
>>> - zip_util.c
>>>     it uses the unicode version of CreateFile (CreateFileW) if the 
>>> original path is >= MAX_PATH.
>>>
>>> - io_util_md.c
>>>     Since zip_util.c (libzip) calls the getPrefixed() function in 
>>> canonicalize_md.c (libjava), the getPrefixed() function needs to be 
>>> exported.
>>
>> I kinda remembered that we once wanted to avoid export an variant of 
>> winFileHandleOpen() from
>> libjava to libzip ... in this case the alternative is to simply 
>> copy/paste the getPrefix into libzip ...
>> but I don't remember the exact concern back then.
> I also thought of copy/paste the getPrefix function into libzip.
> After looking at the lib/CoreLibraries.gmk, I think libzip already has 
> a dependency on libjava:
> $(eval $(call SetupJdkLibrary, BUILD_LIBZIP, \
>     NAME := zip, \
>     OPTIMIZATION := LOW, \
>     EXCLUDES := $(LIBZIP_EXCLUDES), \
>     CFLAGS := $(CFLAGS_JDKLIB) \
>         $(LIBZ_CFLAGS), \
>     CFLAGS_unix := $(BUILD_LIBZIP_MMAP) -UDEBUG, \
>     LDFLAGS := $(LDFLAGS_JDKLIB) \
>         $(call SET_SHARED_LIBRARY_ORIGIN), \
>     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> ))
>
> I've done tier1,2,3 testing and didn't see any new failures.
> I can do higher tier testing if needed.
>
> thanks,
> Calvin
>
> p.s. I didn't see this email until Ioi forwarded it to me since I 
> wasn't in the core-libs-dev alias. (I've subscribed to the alias this 
> morning.)
>
>>
>> -Sherman
>>
>>
>>
>>>
>>>
>>> - java_md.h
>>>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It 
>>> is because the the current usage of the canonicalize() function from 
>>> vm code is to preallocate the output buffer as follows:
>>>             char* canonical_path = 
>>> NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>>>             if (!get_canonical_path(path, canonical_path, 
>>> JVM_MAXPATHLEN)) {
>>>     Also the unix version of canonicalize() function has the 
>>> following check:
>>>             int
>>>            canonicalize(char *original, char *resolved, int len)
>>>            {
>>>                if (len < PATH_MAX) {
>>>                errno = EINVAL;
>>>                return -1;
>>>            }
>>>    So dynamically allocating the output buffer requires more work 
>>> beyond the scope of this change.
>>>
>>> - LongBCP.java
>>>     added a scenario to the test - a long path to a jar file in 
>>> -Xbootclasspath/a.
>>>
>>> Testing: tier-[1,2,3].
>>>
>>> thanks,
>>> Calvin
>>


From mandy.chung at oracle.com  Thu Sep 13 02:04:19 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 12 Sep 2018 19:04:19 -0700
Subject: RFR 8210670 (S): Accept double-dash VM-name options at launch time
In-Reply-To: <20180912141600.365290746@eggemoggin.niobe.net>
References: <20180912141600.365290746@eggemoggin.niobe.net>
Message-ID: <679889f9-27e8-7115-1e93-072b61a22d27@oracle.com>



On 9/12/18 2:16 PM, mark.reinhold at oracle.com wrote:
> To make this trivial enhancement I first had to fix some broken tests,
> so there are two issues and two webrevs here.
>
> 8210669: Some launcher tests assume a pre-JDK 9 run-time image layout
>
>    Two launcher tests, ExecutionEnvironment.java and Test7029048.java (in
>    test/jdk/tools/launcher), still assume the old image layout in which a
>    HotSpot shared library (libjava.so) is found in $JDK/lib/$ARCH/$VMTYPE
>    on Linux and Solaris.  The intermediate $ARCH directory was removed in
>    JDK 9, as part of JEP 220 (Modular Run-Time Images) [1].  Since that
>    time these tests have been succeeding anyway, because they don?t fail
>    when the requested VM is not found.
>
>    The tests should be fixed to fail when the requested VM is not found,
>    and to look for VM shared libraries in the proper location.
>
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8210669
>    Webrev: http://cr.openjdk.java.net/~mr/rev/8210669/

This looks okay.
> 8210670: Accept double-dash VM-name options at launch time
>
>    Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance
>    the Java launcher so that `--server` is accepted to select the server VM,
>    in addition to `-server`, and likewise for any other VMs listed in the
>    $JDK/lib/jvm.cfg file.
>
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8210670
>    Webrev: http://cr.openjdk.java.net/~mr/rev/8210670/

jvm.cfg allows to specify an alias.? Have you considered leveraging 
jvm.cfg alias mechanism?

--server KNOWN ALIASED_TO -server
--client KNOWN ALIASED_TO -client

That'd invoke change in make/Copy-java.base.gmk as well as jvm.cfg to 
require the option
to start with `--` whereas the alias starts with `-`.

Mandy

From xu.y.yin at oracle.com  Thu Sep 13 06:59:59 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 13 Sep 2018 14:59:59 +0800
Subject: [12] RFR 8210695: Create test to cover JDK-8205330 InitialDirContext
 ctor sometimes throws NPE if the server has sent a disconnection
Message-ID: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>

Please have a review for below new added test to cover JDK-8205330, thanks

This test used dummy ldap server to simulate the scenario to send ?Notice of Disconnection? after binding, it will repeat InitialDirContext() for 1000 times (normally the NPE bug should be hit less than 100 times run, but just in case), test failed with NPE if without JDK-8205330 fix change and passed after the fix.

I put this test under test/jdk/com/sun/jndi/ldap/ since the bug root cause is from com.sun.jndi.ldap.LdapClient, feel free to let me know if it should be moved to other suitable folder.

bug: https://bugs.openjdk.java.net/browse/JDK-8210695
webrev: http://cr.openjdk.java.net/~xyin/8210695/webrev.00/

Regards,
Chris

From Alan.Bateman at oracle.com  Thu Sep 13 07:33:25 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Sep 2018 08:33:25 +0100
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
Message-ID: <11da04fd-b711-32b6-59a0-0660efb731a2@oracle.com>

On 11/09/2018 17:04, Stephen Colebourne wrote:
> :
> This is a broader question for new methods in the JDK, not just this
> one. I don't think anyone has come up with a "style guide" for when to
> use Stream returning as opposed to list-returning methods.
>
> What I can say is that I think List is the better fit here, because:
> - the result is not large
> - the result may well be stored somewhere (method should guarantee
> result is immutable)
> - a List is simpler conceptually than Stream as a result type (eg.
> serial vs parallel)
>
> Personally, I only tend to return Stream if I the particular method is
> returning a very large data set.
>
There are several discussion points around this aspect of API design. 
One of the most important questions to ask is whether a stream or 
collection is more useful to the caller. For the API under discussion 
then we have several examples in the JDK that process the class path or 
module path. One example involves mapping the elements of the class path 
to file URLs and into an array to create a URLClassLoader. Another maps 
the elements to Path objects and into an array to create a ModuleFinder. 
Another maps the elements to Path objects and performs an action on each 
element. Stuart brings up the empty path case which, depending on 
context, may need to be filtered. The examples so far iterate over the 
elements once and an intermediate/cached collection isn't needed. On the 
other hand, I think Roger's main use-case is representing the value of 
the java.class.path property as a List<Path> which will may involve 
caching an unmodifiable list.

-Alan


From Alan.Bateman at oracle.com  Thu Sep 13 07:36:47 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Sep 2018 08:36:47 +0100
Subject: [12] RFR of JDK-8209772: Refactor shell test
 java/util/ServiceLoader/basic/basic.sh to java
In-Reply-To: <77269474-6f15-0490-610d-de8adb1c169f@oracle.com>
References: <77269474-6f15-0490-610d-de8adb1c169f@oracle.com>
Message-ID: <11be4585-b49a-6a0d-857a-cb1d8da17217@oracle.com>

On 12/09/2018 08:22, Amy Lu wrote:
> test/jdk/java/util/ServiceLoader/basic/basic.sh
>
> Please review this patch to refactor above shell script test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8209772
> webrev: http://cr.openjdk.java.net/~amlu/8209772/webrev.00/
This looks okay to me but it isn't immediately clear if the output/error 
streams from the launched VMs will be in the .jtr file. In other tests 
we have used the OutputAnalyzer's outputTo and errorTo and I wonder if 
it's needed here.

-Alan

From sgehwolf at redhat.com  Thu Sep 13 07:47:02 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 13 Sep 2018 09:47:02 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <5dc2351a-1432-ff66-fa74-7712726408ec@oracle.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <22c48bfc-034d-f00d-1681-0c6743d4c908@oracle.com>
 <7deab5261804125acd2686ce37e90aa1bd44dfe8.camel@redhat.com>
 <bfb6743e-7657-ab9f-8596-08f2abb02e5e@oracle.com>
 <5dc2351a-1432-ff66-fa74-7712726408ec@oracle.com>
Message-ID: <7c4ac53c152649012d12fefd9f531a99fb9ff0d7.camel@redhat.com>

On Thu, 2018-09-13 at 11:00 +1000, David Holmes wrote:
> Correction ...
> 
> On 13/09/2018 8:31 AM, David Holmes wrote:
> > On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
> > > On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> > > > But I don't understand why the optimization setting is being tied to the
> > > > availability of the -ffp-contract flag?
> > > 
> > > In configure we perform a check for gcc or clang whether that flag is
> > > supported. If it is, it would be non-empty exactly having -ffp-contract
> > > as value. It could be another set of flags for other arches if somebody
> > > wanted to do the same, fwiw. In JDK 8, for example, it's "-mno-fused-
> > > madd -fno-strict-aliasing" for ppc64:
> > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/2660b127b407/make/lib/CoreLibraries.gmk#l63 
> > > 
> > > 
> > > We need support for that flag (or a set of flags) when we optimize
> > > fdlibm since otherwise we would lose precision. If the flag is empty
> > > we'd not optimize as we can't guarantee precision. That's why we tie
> > > optimization to the availability of that flag. The expectation is for
> > > this flag to be available on gcc/clang arches only at this point. Does
> > > that make sense?
> > 
> > Yes that makes sense - thanks. I didn't quite glean that from the comment:
> > 
> >    42 # If FDLIBM_CFLAGS is non-empty we know that we can optimize
> >    43 # fdlibm by adding those extra C flags. Currently GCC,
> 
> I think this should say "when adding" not "by adding".

OK. Thanks, David. I'll change that before pushing.

Cheers,
Severin

> Thanks,
> David
> 
> >    44 # and clang only.
> >    45 ifneq ($(FDLIBM_CFLAGS), )
> >    46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> > 
> > But now I can read it and understand.
> > 
> > Thanks,
> > David
> > 
> > > Thanks,
> > > Severin
> > > 


From amy.lu at oracle.com  Thu Sep 13 08:27:47 2018
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 13 Sep 2018 16:27:47 +0800
Subject: [12] RFR of JDK-8209772: Refactor shell test
 java/util/ServiceLoader/basic/basic.sh to java
In-Reply-To: <11be4585-b49a-6a0d-857a-cb1d8da17217@oracle.com>
References: <77269474-6f15-0490-610d-de8adb1c169f@oracle.com>
 <11be4585-b49a-6a0d-857a-cb1d8da17217@oracle.com>
Message-ID: <c11c5f48-e386-587c-5c69-5f27a7830429@oracle.com>

On 2018/9/13 3:36 PM, Alan Bateman wrote:
> On 12/09/2018 08:22, Amy Lu wrote:
>> test/jdk/java/util/ServiceLoader/basic/basic.sh
>>
>> Please review this patch to refactor above shell script test to java.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209772
>> webrev: http://cr.openjdk.java.net/~amlu/8209772/webrev.00/
> This looks okay to me but it isn't immediately clear if the 
> output/error streams from the launched VMs will be in the .jtr file. 
> In other tests we have used the OutputAnalyzer's outputTo and errorTo 
> and I wonder if it's needed here.

Thank you Alan for your review.

I double checked, the output/error are in .jtr file (this has been taken 
care of by ProcessTools::executeCommand).

Thanks,
Amy

>
> -Alan


From daniel.fuchs at oracle.com  Thu Sep 13 09:23:29 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 13 Sep 2018 10:23:29 +0100
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
Message-ID: <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>

Hi Joe,

On 13/09/2018 00:25, Lance Andersen wrote:
> Hi Joe,
> 
> The change  seems reasonable

Agreed. However the following condition in ToStream::handleEscaping
is a bit cryptic:

1155             if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
1156                 i++ ; // process two input characters
1157             }

could the comment be fleshed out to explain it?

I suspect that: `(ihs && (i + 1 < end))` means that
`writeUTF16Surrogate(c, ch, i, end);` has written the two surrogate, in
which case i should be incremented in order to skip the low surrogate
which has just been written.

I am not sure what `(ils && i != 0)` means, though...

best regards

-- daniel

> 
>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review a patch for a situation where a surrogate pair is at the edge of a buffer. What the existing impl did was to report it as an error. This patch fixes it by caching the high surrogate and prints it out along with the low surrogate. Similar issue exists also in the CDATA section and is fixed in this patch. The CDATA impl had a couple of bugs where an indent could be written inside the CDATA and an unicode character written in between two CDATA sections. Both are fixed in this patch.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>
>> 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 daniel.fuchs at oracle.com  Thu Sep 13 09:43:39 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 13 Sep 2018 10:43:39 +0100
Subject: [12] RFR 8210695: Create test to cover JDK-8205330
 InitialDirContext ctor sometimes throws NPE if the server has sent a
 disconnection
In-Reply-To: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>
References: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>
Message-ID: <02180a46-41cd-3e66-59e0-3738fa4180ae@oracle.com>

Hi Chris,

Thanks a lot for writing this test!

   60         serverSocket = new ServerSocket(0);
   69         env.put(Context.PROVIDER_URL, 
String.format("ldap://localhost:%d/",

For robustness of the test I would suggest using
InetAddress.getLoopbackAddress() explicitly, to
avoid having the dummy server listen on all interfaces.
Listening on all interfaces has proved to be a source of
intermittent failures in the past, possibly due
to different port reuse strategies at OS level.

   88                     System.out.println("(" + count + "/" + 
REPEAT_COUNT
   89                             + ") It's ok to get NamingException: " 
+ ne);
   90                     // for debug
   91                     ne.printStackTrace();

I think it would be better in that case to print the stactrace on
stdout (i.e. use ne.printStackTrace(System.out)), since that
exception is expected and not considered as an error.

best regards,

-- daniel


On 13/09/2018 07:59, Chris Yin wrote:
> Please have a review for below new added test to cover JDK-8205330, thanks
> 
> This test used dummy ldap server to simulate the scenario to send ?Notice of Disconnection? after binding, it will repeat InitialDirContext() for 1000 times (normally the NPE bug should be hit less than 100 times run, but just in case), test failed with NPE if without JDK-8205330 fix change and passed after the fix.
> 
> I put this test under test/jdk/com/sun/jndi/ldap/ since the bug root cause is from com.sun.jndi.ldap.LdapClient, feel free to let me know if it should be moved to other suitable folder.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8210695
> webrev: http://cr.openjdk.java.net/~xyin/8210695/webrev.00/
> 
> Regards,
> Chris
> 


From magnus.ihse.bursie at oracle.com  Thu Sep 13 13:07:04 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 13 Sep 2018 15:07:04 +0200
Subject: Why static_jli for java/javaw on Windows?
Message-ID: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>

On Windows, we compile two versions of libjli, one normal dynamic dll, 
and one static library *). Then when we create our launchers, we link 
with the normal, dynamic libjli for all launchers, except java.exe and 
javaw.exe, which are linked with the static library.

The build system needs to do some elaborate dancing to support this odd 
behavior, which affects code quality negatively. I would therefore like 
to remove this special treatment of java.exe and javaw.exe.

I've done some extensive amount of code archeology to try and determine 
where and how this was added. The only thing I can figure out is that it 
was this way in the old build system, in the initial load of OpenJDK. In 
jdk/make/java/main/java/Makefile, two comments might shed some light:

# Statically link java to avoid the dependency on msvcr71.dll.
and
# Statically link java to avoid the dependency on jli.dll.

Apparently, someone was trying to get rid of dll dependencies from 
java.exe. Why that would be desirable it does not say. Neither why this 
should not apply to all other launchers. (Perhaps there were not that 
many in these days?)

Do anyone think this still seems relevant? Otherwise I'd like to get rid 
of this hack, and link java and javaw just like all the other launchers.

/Magnus

*) Yeah, we do other funky stuff with libjli on other platforms as well. 
But for now, I'm focusing on Windows.

From Alan.Bateman at oracle.com  Thu Sep 13 13:32:31 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Sep 2018 14:32:31 +0100
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
Message-ID: <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>



On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
> :
>
> Apparently, someone was trying to get rid of dll dependencies from 
> java.exe. Why that would be desirable it does not say. Neither why 
> this should not apply to all other launchers. (Perhaps there were not 
> that many in these days?)
>
> Do anyone think this still seems relevant? Otherwise I'd like to get 
> rid of this hack, and link java and javaw just like all the other 
> launchers.
>
I don't know if it is still needed but it seems to be related to the 
upgrade to VC 7 and an issue related to redistribution issue of the MS 
runtime. JDK-6282039 and JDK-6382014 have some info on this.

-Alan.

From erik.joelsson at oracle.com  Thu Sep 13 16:14:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Sep 2018 09:14:33 -0700
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
 <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
Message-ID: <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>

Hello,

Reading that bug, it seems the problem is when the installer copies 
java.exe into the Windows system directory. In that case, it may not 
have access to the msvcr re-distributables. I will try to find out if 
our installers are still doing this.

/Erik


On 2018-09-13 06:32, Alan Bateman wrote:
>
>
> On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
>> :
>>
>> Apparently, someone was trying to get rid of dll dependencies from 
>> java.exe. Why that would be desirable it does not say. Neither why 
>> this should not apply to all other launchers. (Perhaps there were not 
>> that many in these days?)
>>
>> Do anyone think this still seems relevant? Otherwise I'd like to get 
>> rid of this hack, and link java and javaw just like all the other 
>> launchers.
>>
> I don't know if it is still needed but it seems to be related to the 
> upgrade to VC 7 and an issue related to redistribution issue of the MS 
> runtime. JDK-6282039 and JDK-6382014 have some info on this.
>
> -Alan.


From Roger.Riggs at Oracle.com  Thu Sep 13 17:21:26 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 13 Sep 2018 13:21:26 -0400
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <11da04fd-b711-32b6-59a0-0660efb731a2@oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
 <11da04fd-b711-32b6-59a0-0660efb731a2@oracle.com>
Message-ID: <462c5054-075a-e43c-a838-5460ddbbe314@Oracle.com>

Hi,

Defining a SearchPath class does have a number of benefits as Mark outlined.

Consider:

public class SearchPath {
 ??? public static SearchPath of(String searchPath) {...}
public static SearchPath of(List<String> elements) {...}
public Stream<String> stream() {...}
public List<String> asList() {...}
 ??? public String toString() {...}
 ??? private SearchPath() {};
}

A SearchPath can be constructed from various forms of search path 
elements and can create other forms as needed.
As a class it would be extensible and can start small and grow as needed.

Examples:
 ??? ??? List<String> list = SearchPath.of("a:b:c").asList();

 ????Path p = SearchPath.of("x:y:z").stream()
 ?? ? ??? .filter(Predicate.not(String::isEmpty))
 ?? ? ??? .map(Path::of)
 ??? ??? ???? .filter(Files::isDirectory)
 ???????????? .filter(q -> Files.exists(q.resolve("x.jar)))
 ?? ? ??? .findFirst()
 ?? ? ??? .orElseThrow();

If that seems like a reasonable base, I (or some other volunteer) can 
flesh it out with the suggestions.

Thanks, Roger

On 9/13/2018 3:33 AM, Alan Bateman wrote:
> On 11/09/2018 17:04, Stephen Colebourne wrote:
>> :
>> This is a broader question for new methods in the JDK, not just this
>> one. I don't think anyone has come up with a "style guide" for when to
>> use Stream returning as opposed to list-returning methods.
>>
>> What I can say is that I think List is the better fit here, because:
>> - the result is not large
>> - the result may well be stored somewhere (method should guarantee
>> result is immutable)
>> - a List is simpler conceptually than Stream as a result type (eg.
>> serial vs parallel)
>>
>> Personally, I only tend to return Stream if I the particular method is
>> returning a very large data set.
>>
> There are several discussion points around this aspect of API design. 
> One of the most important questions to ask is whether a stream or 
> collection is more useful to the caller. For the API under discussion 
> then we have several examples in the JDK that process the class path 
> or module path. One example involves mapping the elements of the class 
> path to file URLs and into an array to create a URLClassLoader. 
> Another maps the elements to Path objects and into an array to create 
> a ModuleFinder. Another maps the elements to Path objects and performs 
> an action on each element. Stuart brings up the empty path case which, 
> depending on context, may need to be filtered. The examples so far 
> iterate over the elements once and an intermediate/cached collection 
> isn't needed. On the other hand, I think Roger's main use-case is 
> representing the value of the java.class.path property as a List<Path> 
> which will may involve caching an unmodifiable list.
>
> -Alan
>


From jonathan.gibbons at oracle.com  Thu Sep 13 17:30:17 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 13 Sep 2018 10:30:17 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <462c5054-075a-e43c-a838-5460ddbbe314@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
 <11da04fd-b711-32b6-59a0-0660efb731a2@oracle.com>
 <462c5054-075a-e43c-a838-5460ddbbe314@Oracle.com>
Message-ID: <772a5fa3-54cc-aaef-a382-6bba565775d6@oracle.com>

+1

-- Jon


On 9/13/18 10:21 AM, Roger Riggs wrote:
> Hi,
>
> Defining a SearchPath class does have a number of benefits as Mark 
> outlined.
>
> Consider:
>
> public class SearchPath {
> ??? public static SearchPath of(String searchPath) {...}
> public static SearchPath of(List<String> elements) {...}
> public Stream<String> stream() {...}
> public List<String> asList() {...}
> ??? public String toString() {...}
> ??? private SearchPath() {};
> }
>
> A SearchPath can be constructed from various forms of search path 
> elements and can create other forms as needed.
> As a class it would be extensible and can start small and grow as needed.
>
> Examples:
> ??? ??? List<String> list = SearchPath.of("a:b:c").asList();
>
> ????Path p = SearchPath.of("x:y:z").stream()
> ?? ? ??? .filter(Predicate.not(String::isEmpty))
> ?? ? ??? .map(Path::of)
> ??? ??? ???? .filter(Files::isDirectory)
> ???????????? .filter(q -> Files.exists(q.resolve("x.jar)))
> ?? ? ??? .findFirst()
> ?? ? ??? .orElseThrow();
>
> If that seems like a reasonable base, I (or some other volunteer) can 
> flesh it out with the suggestions.
>
> Thanks, Roger
>
> On 9/13/2018 3:33 AM, Alan Bateman wrote:
>> On 11/09/2018 17:04, Stephen Colebourne wrote:
>>> :
>>> This is a broader question for new methods in the JDK, not just this
>>> one. I don't think anyone has come up with a "style guide" for when to
>>> use Stream returning as opposed to list-returning methods.
>>>
>>> What I can say is that I think List is the better fit here, because:
>>> - the result is not large
>>> - the result may well be stored somewhere (method should guarantee
>>> result is immutable)
>>> - a List is simpler conceptually than Stream as a result type (eg.
>>> serial vs parallel)
>>>
>>> Personally, I only tend to return Stream if I the particular method is
>>> returning a very large data set.
>>>
>> There are several discussion points around this aspect of API design. 
>> One of the most important questions to ask is whether a stream or 
>> collection is more useful to the caller. For the API under discussion 
>> then we have several examples in the JDK that process the class path 
>> or module path. One example involves mapping the elements of the 
>> class path to file URLs and into an array to create a URLClassLoader. 
>> Another maps the elements to Path objects and into an array to create 
>> a ModuleFinder. Another maps the elements to Path objects and 
>> performs an action on each element. Stuart brings up the empty path 
>> case which, depending on context, may need to be filtered. The 
>> examples so far iterate over the elements once and an 
>> intermediate/cached collection isn't needed. On the other hand, I 
>> think Roger's main use-case is representing the value of the 
>> java.class.path property as a List<Path> which will may involve 
>> caching an unmodifiable list.
>>
>> -Alan
>>
>


From calvin.cheung at oracle.com  Thu Sep 13 17:30:00 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 13 Sep 2018 10:30:00 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize() function
 to handle long path on windows
In-Reply-To: <5B99C2C3.3000302@oracle.com>
References: <5B96BB03.3070503@oracle.com> <5B9706BA.4080409@oracle.com>
 <5B999E36.90600@oracle.com> <5B99C2C3.3000302@oracle.com>
Message-ID: <5B9A9E98.2000606@oracle.com>

Hi Sherman,

I'll change the comment to:

130             fname,              /* path name in multibyte char */

thanks,
Calvin

On 9/12/18, 6:52 PM, Xueming Shen wrote:
> Hi Calvin,
>
> I believe I was thinking of keeping the "getPrefixed" as an 
> implementation details and
> instead exporting a "A" version of winFileHandleOpen() back then. But 
> I don't have a
> strong opinion on this one, so your approach looks fine.
>
> No, I don't have a better idea for now to avoid those mb->ws->mb as 
> long as the canonicalize()
> and zip_open() are two separate invocations. But since they are only 
> for > max_path path. I'm
> fine with it.
>
> Yes, I think it's time to consider to migrate from interpreting the 
> char* as "mb chars" to probably
> "utf8 chars" (take a step back, I don't think it's easy to do to 
> actually a wchar interface) for windows
> platform, but that would be a separate and big rfes.
>
> nit:
>
> 130             fname,              /* Ascii char path name */
>
> the comment probably should be "path name in mb char", or ANSI charset.
>
> Thanks,
>
> -Sherman
>
> On 9/12/18, 4:16 PM, Calvin Cheung wrote:
>> Hi Sherman,
>>
>> Thanks for your review.
>> Please refer to my reply below...
>>
>> On 9/10/18, 5:05 PM, Xueming Shen wrote:
>>> On 9/10/18, 11:42 AM, Calvin Cheung wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>>>>
>>>> Please review this change for handling long path specified in the 
>>>> -Xbootclasspath/a on windows.
>>>>
>>>> Highlight of changes:
>>>> - canonicalize_md.c
>>>>     it makes use of the unicode version of canonicalize 
>>>> (wcanonicalize) if the original path is >= MAX_PATH.
>>> So we are converting mb->wc->mb in wcanonicalize (when > max_path), 
>>> and then feed the
>>> resulting path into ZFILE_Open, in which we again do mb->wc-> + 
>>> prefix -> CreateFileW(...)?
>> That's the minimal change I could come up with. Let me know if you 
>> have other suggestions.
>>>
>>> Maybe it's time to consider a "wchar" interface between vm and 
>>> libraries.
>> Good idea. I think it should be done in a separate RFE.
>>> Maybe it's fine here given we
>>> are only do this for > max_path case?
>> This was done so that this change has no impact on the <= MAX_PATH case.
>>>
>>> Alan, now reading the win version canonicalize(...), remind me 
>>> what's the real purpose of doing
>>> FindFirstFile/FindClose() here? the API appears to suggest it is 
>>> used to find the first match if there
>>> is/are wildcards but we actually have checked/rejected the wildcards 
>>> at the very beginning ? To
>>> get the "real name" for case?
>>>
>>>>
>>>> - zip_util.c
>>>>     it uses the unicode version of CreateFile (CreateFileW) if the 
>>>> original path is >= MAX_PATH.
>>>>
>>>> - io_util_md.c
>>>>     Since zip_util.c (libzip) calls the getPrefixed() function in 
>>>> canonicalize_md.c (libjava), the getPrefixed() function needs to be 
>>>> exported.
>>>
>>> I kinda remembered that we once wanted to avoid export an variant of 
>>> winFileHandleOpen() from
>>> libjava to libzip ... in this case the alternative is to simply 
>>> copy/paste the getPrefix into libzip ...
>>> but I don't remember the exact concern back then.
>> I also thought of copy/paste the getPrefix function into libzip.
>> After looking at the lib/CoreLibraries.gmk, I think libzip already 
>> has a dependency on libjava:
>> $(eval $(call SetupJdkLibrary, BUILD_LIBZIP, \
>>     NAME := zip, \
>>     OPTIMIZATION := LOW, \
>>     EXCLUDES := $(LIBZIP_EXCLUDES), \
>>     CFLAGS := $(CFLAGS_JDKLIB) \
>>         $(LIBZ_CFLAGS), \
>>     CFLAGS_unix := $(BUILD_LIBZIP_MMAP) -UDEBUG, \
>>     LDFLAGS := $(LDFLAGS_JDKLIB) \
>>         $(call SET_SHARED_LIBRARY_ORIGIN), \
>>     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>> ))
>>
>> I've done tier1,2,3 testing and didn't see any new failures.
>> I can do higher tier testing if needed.
>>
>> thanks,
>> Calvin
>>
>> p.s. I didn't see this email until Ioi forwarded it to me since I 
>> wasn't in the core-libs-dev alias. (I've subscribed to the alias this 
>> morning.)
>>
>>>
>>> -Sherman
>>>
>>>
>>>
>>>>
>>>>
>>>> - java_md.h
>>>>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. 
>>>> It is because the the current usage of the canonicalize() function 
>>>> from vm code is to preallocate the output buffer as follows:
>>>>             char* canonical_path = 
>>>> NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>>>>             if (!get_canonical_path(path, canonical_path, 
>>>> JVM_MAXPATHLEN)) {
>>>>     Also the unix version of canonicalize() function has the 
>>>> following check:
>>>>             int
>>>>            canonicalize(char *original, char *resolved, int len)
>>>>            {
>>>>                if (len < PATH_MAX) {
>>>>                errno = EINVAL;
>>>>                return -1;
>>>>            }
>>>>    So dynamically allocating the output buffer requires more work 
>>>> beyond the scope of this change.
>>>>
>>>> - LongBCP.java
>>>>     added a scenario to the test - a long path to a jar file in 
>>>> -Xbootclasspath/a.
>>>>
>>>> Testing: tier-[1,2,3].
>>>>
>>>> thanks,
>>>> Calvin
>>>
>

From Roger.Riggs at Oracle.com  Thu Sep 13 17:58:09 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 13 Sep 2018 13:58:09 -0400
Subject: [12]: RFR: 8209167: Use CLDR's time zone mappings for Windows
In-Reply-To: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
 <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
Message-ID: <787cdcec-2727-048d-cdb1-39a6dd952a75@Oracle.com>

Hi Naoto,

The code to extract from CLDR data looks fine.

+1

Thanks, Roger


On 9/12/2018 1:33 PM, naoto.sato at oracle.com wrote:
> Hi Magnus, Erik,
>
> Thank you for your comments. I updated the webrev according to your 
> suggestions:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
>
> As to the duplicated "common" in the dependency, yes that's a separate 
> issue. Since it's obvious, I included the fix with this changeset (it 
> was actually described as a comment in the jira issue).
>
> Naoto
>
> On 9/12/18 9:08 AM, Erik Joelsson wrote:
>> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-09-10 23:34, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>>
>>> Some comments:
>>> In make/copy/Copy-java.base.gmk:
>>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>>
>>> The findstring construct is hard to read and only needed when we 
>>> test more than one OS. Please rewrite as a single ifeq test for aix.
>>>
>>> In GensrcCLDR.gmk:
>>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>>> generate it, there's just a dependency..?
>>>
>> It's generated by the same rule as the other file. This is the 
>> easiest workaround for two files generated from the same rule. It 
>> sort of works (for clean builds and if the input is chagned), but 
>> won't handle all cases where one file is removed externally and the 
>> other is not. I suggested this construct to Naoto. Perhaps a comment 
>> explaining this would be good.
>>> The removal of the duplicate "common", that seems like a separate 
>>> bug fix?
>>>
>> It does indeed. Before this fix, the wildcards must have returned empty.
>>
>> /Erik
>>> /Magnus
>>>
>>>>
>>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>>> dynamically generated at the build time, using CLDR's data file 
>>>> (windowsZones.xml)
>>>>
>>>> Naoto
>>>
>>


From mandy.chung at oracle.com  Thu Sep 13 18:44:12 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 13 Sep 2018 11:44:12 -0700
Subject: Review Request JDK-8210721: Replace legacy serial exception field
 with Throwable::cause
Message-ID: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>

A few exception classes such as ExceptionInInitializerError, 
InvocationTargetException,
etc were defined prior to the exception chaining facility and provides 
the API to get
the cause of the exception. These classes keep its legacy serial field e.g.
ExceptionInInitializerError::exception to get the serialization to work 
on older JDK version.

During the review of JDK-8209553 [1], Peter and Joe suggest to remove 
this legacy
serial field and implement the serialization using 
serialPersistentFields, readObject
and writeObject.?? It turns out that these redundant fields were removed 
when the
exception chaining support was initially implemented but it got reverted 
to fix
JDK-4385429 since Throwable::setCause rejects any further change as
Throwable::cause has been initialized to null.

This patch removes these legacy serial field and stores the cause in 
Throwable::cause.
It's essentially a redo for the fix for JDK-4385429.

webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html 


From mandy.chung at oracle.com  Thu Sep 13 18:49:16 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 13 Sep 2018 11:49:16 -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: <ccc391ff-b17a-77d9-defb-8cb451fe9c0b@oracle.com>


On 8/16/18 4:48 PM, joe darcy wrote:
> 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.
>

Looking at the history, it turns out that these redundant fields were 
removed at one point when the exception chaining support was initially 
implemented but it got reverted to fix JDK-4385429.??? I have posted a 
proposed patch to remove the private Throwable exception field and also 
clean up a few other exception classes as a separate JBS issue.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055415.html

Mandy

From ivan.gerasimov at oracle.com  Thu Sep 13 19:12:00 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 13 Sep 2018 12:12:00 -0700
Subject: RFR 8098798: Thread.join(ms) on Linux still affected by changes
 to the time-of-day clock
In-Reply-To: <13faf62f-9c31-e7ca-d7d4-bec89b139833@Oracle.com>
References: <42ed08ee-edcb-f42f-e723-cb9d563cec88@Oracle.com>
 <CA+kOe0_-4yrbreOuuvmYxACG8chMMxGJ5s9mZXwU6j91E27DPg@mail.gmail.com>
 <b667c610-ad76-3c21-f954-1f0867cff28c@Oracle.com>
 <7d6bb15b-6ba5-42d5-7769-095bb9cb77a1@oracle.com>
 <13faf62f-9c31-e7ca-d7d4-bec89b139833@Oracle.com>
Message-ID: <06f8752a-96aa-7cc3-e7f4-4fc8b9f8ae52@oracle.com>

Thank you Roger!

The fix addresses the issue with System.currentTimeMillis() and 
returning early from sleep()/join(), so it looks good!

I think it's better to wrap the line 1304 up to improve readability.  
Maybe import j.u.c.TimeUnit.NANOSECONDS, so that `TimeUnit.' could be 
omitted?

No further comments from me.

With kind regards,

Ivan


On 9/10/18 9:54 AM, Roger Riggs wrote:
> Hi Ivan,
>
> Thanks for the suggestion.
> Webrev updated:
>
>    http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>
> Thanks, Roger
>
> On 9/4/2018 3:38 PM, Ivan Gerasimov wrote:
>> Thank you Roger!
>>
>> I'm not sure if it plays any significant role, but an unnecessary 
>> call to nanoTime() after wait(delay) could be avoided with the code 
>> like this:
>>
>>     if (millis > 0) {
>>         if (isAlive()) {
>>             final long startTime = System.nanoTime();
>>             long delay = millis;
>>             do {
>>                 wait(delay);
>>             } while (isAlive() && (delay = millis - 
>> TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime)) > 0);
>>         }
>>     } else if (millis == 0) {
>>
>>
>> With kind regards,
>> Ivan
>>
>>
>> On 9/4/18 12:02 PM, Roger Riggs wrote:
>>> Hi Martin, Ivan,
>>>
>>> Thanks for the suggestions.
>>>
>>> Update in place:
>>> http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/
>>>
>>> On 8/29/2018 5:36 PM, Martin Buchholz wrote:
>>>> 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.
>>>>
>>> Not trivial since a long cannot hold the combined time of 
>>> millis(long) and nanos (long) in a TimeUnit(Nanos)
>>> and the cumulative wait time needs to be measured by System.nanoTime().
>>>
>>>> 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
>>> ok
>>>>
>>>> (I prefer the variable name "startTime")
>>> ok
>>>>
>>>> (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))
>>> ok,
>>>>
>>>> (I would reorder clauses to first check the common case millis > 0, 
>>>> then millis == 0, last the error case millis < 0)
>>> ok
>>>>
>>>> (it's a bad API that millis < 0 is an error)
>>> too late for a behavior change though I suppose its in the direction 
>>> of not getting error instead of the opposite....
>>>
>>>
>>> An Observation:
>>>
>>> Join(ms) and join(ms, ns) might wait a bit longer than strictly 
>>> necessary because the bottom out in Object.wait(ms).
>>> It might be better if both ended up calling Object.wait(ms, ns).
>>> But since Object.wait(ms,ns) rounds up to Object.wait(ms) that won't 
>>> make a difference and to take advantage
>>> of a finer clock resolution would mean native/vm changes to support 
>>> object.wait(ms, ns).
>>>
>>> I'm inclined to address only the immediate issues raised in the 
>>> early return and the clock dependency now.
>>>
>>> (BTW, I found no tests for Thread.sleep or .join.)
>>>
>>> Thanks, Roger
>>>
>>>>
>>>>
>>>> On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs 
>>>> <Roger.Riggs at oracle.com <mailto: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/
>>>> <http://cr.openjdk.java.net/%7Erriggs/webrev-thread-early-8098798/>
>>>>
>>>>     Thanks, Roger
>>>>
>>>>
>>>
>>>
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From magnus.ihse.bursie at oracle.com  Thu Sep 13 19:22:33 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 13 Sep 2018 21:22:33 +0200
Subject: [12]: RFR: 8209167: Use CLDR's time zone mappings for Windows
In-Reply-To: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
 <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
Message-ID: <09fb76fa-3924-8968-aae0-ce86520a8950@oracle.com>



On 2018-09-12 19:33, naoto.sato at oracle.com wrote:
> Hi Magnus, Erik,
>
> Thank you for your comments. I updated the webrev according to your 
> suggestions:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
Looks good to me.

/Magnus

>
> As to the duplicated "common" in the dependency, yes that's a separate 
> issue. Since it's obvious, I included the fix with this changeset (it 
> was actually described as a comment in the jira issue).
>
> Naoto
>
> On 9/12/18 9:08 AM, Erik Joelsson wrote:
>> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-09-10 23:34, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>>
>>> Some comments:
>>> In make/copy/Copy-java.base.gmk:
>>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>>
>>> The findstring construct is hard to read and only needed when we 
>>> test more than one OS. Please rewrite as a single ifeq test for aix.
>>>
>>> In GensrcCLDR.gmk:
>>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>>> generate it, there's just a dependency..?
>>>
>> It's generated by the same rule as the other file. This is the 
>> easiest workaround for two files generated from the same rule. It 
>> sort of works (for clean builds and if the input is chagned), but 
>> won't handle all cases where one file is removed externally and the 
>> other is not. I suggested this construct to Naoto. Perhaps a comment 
>> explaining this would be good.
>>> The removal of the duplicate "common", that seems like a separate 
>>> bug fix?
>>>
>> It does indeed. Before this fix, the wildcards must have returned empty.
>>
>> /Erik
>>> /Magnus
>>>
>>>>
>>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>>> dynamically generated at the build time, using CLDR's data file 
>>>> (windowsZones.xml)
>>>>
>>>> Naoto
>>>
>>


From lance.andersen at oracle.com  Thu Sep 13 19:32:24 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 13 Sep 2018 15:32:24 -0400
Subject: Review Request JDK-8210721: Replace legacy serial exception field
 with Throwable::cause
In-Reply-To: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
References: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
Message-ID: <18817B06-CC97-4CCB-B189-9F7C98273841@oracle.com>

Looks good Mandy...
> On Sep 13, 2018, at 2:44 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> A few exception classes such as ExceptionInInitializerError, InvocationTargetException,
> etc were defined prior to the exception chaining facility and provides the API to get
> the cause of the exception. These classes keep its legacy serial field e.g.
> ExceptionInInitializerError::exception to get the serialization to work on older JDK version.
> 
> During the review of JDK-8209553 [1], Peter and Joe suggest to remove this legacy
> serial field and implement the serialization using serialPersistentFields, readObject
> and writeObject.   It turns out that these redundant fields were removed when the
> exception chaining support was initially implemented but it got reverted to fix
> JDK-4385429 since Throwable::setCause rejects any further change as
> Throwable::cause has been initialized to null.
> 
> This patch removes these legacy serial field and stores the cause in Throwable::cause.
> It's essentially a redo for the fix for JDK-4385429.
> 
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/
> 
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html 

 <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 jason_mehrens at hotmail.com  Thu Sep 13 19:47:42 2018
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 13 Sep 2018 19:47:42 +0000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <ccc391ff-b17a-77d9-defb-8cb451fe9c0b@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>,
 <ccc391ff-b17a-77d9-defb-8cb451fe9c0b@oracle.com>
Message-ID: <CY4PR18MB132024BC98ED3BEC70BA80C5831A0@CY4PR18MB1320.namprd18.prod.outlook.com>

Hi Mandy,

Like in previous patches, I advocated for using 'super.getCause()' in writeObject to avoid any subclass hooking into serialization.  I even lean towards the legacy getXXX methods call super.getCause too so they are compatible with previous behavior.

Does Throwable.setCause need a more obscure name encase there are subclasses of throwable in the wild with that signature?

EIIE has double semi-colon in the constructor and PAE has a random javadoc modification.

Cheers,

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, September 13, 2018 1:49 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:
> 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.
>

Looking at the history, it turns out that these redundant fields were
removed at one point when the exception chaining support was initially
implemented but it got reverted to fix JDK-4385429.    I have posted a
proposed patch to remove the private Throwable exception field and also
clean up a few other exception classes as a separate JBS issue.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055415.html

Mandy

From mandy.chung at oracle.com  Thu Sep 13 20:50:58 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 13 Sep 2018 13:50:58 -0700
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <CY4PR18MB132024BC98ED3BEC70BA80C5831A0@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>
 <ccc391ff-b17a-77d9-defb-8cb451fe9c0b@oracle.com>
 <CY4PR18MB132024BC98ED3BEC70BA80C5831A0@CY4PR18MB1320.namprd18.prod.outlook.com>
Message-ID: <a7d354e2-60f5-6210-3fc0-da96deac9554@oracle.com>



On 9/13/18 12:47 PM, Jason Mehrens wrote:
> Hi Mandy,
>
> Like in previous patches, I advocated for using 'super.getCause()' in writeObject to avoid any subclass hooking into serialization.  I even lean towards the legacy getXXX methods call super.getCause too so they are compatible with previous behavior.

Good point.? It's probably rare to have subclasses of these types and 
overrides getCause method.? In any case I agree it should call 
super.getCause for correctness.? I also added a test case with 
overridden getCause method.

http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.01/
> Does Throwable.setCause need a more obscure name encase there are subclasses of throwable in the wild with that signature?

This is package-private method.
> EIIE has double semi-colon in the constructor and PAE has a random javadoc modification.
>

Good catch!? It's cleaned up.

Mandy

From Sergey.Bylokhov at oracle.com  Thu Sep 13 21:43:10 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 13 Sep 2018 14:43:10 -0700
Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class
 can be dropped
Message-ID: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>

Hello.
Please review fix for jdk12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8210693

The client code has a "com.sun.awt.SecurityWarning" class which at some 
point in the past, JDK 6u10, was used as a kind of "public" API.

During development of jdk9 it was considered that this API is not 
supported and may be removed in the future: JDK-8051640.
In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) 
and can be dropped in 12.

In the fix these things were removed:
  - com/sun/awt/SecurityWarning.java
  - The test for SecurityWarning class
  - Test groups, because SecurityWarning is the latest class in 
"com/sun/awt" package
  - The reference to "com/sun/awt" in the "default.policy"

(cc) core-libs-dev:
I am not sure who is responsible to review the change in "default.policy".


-- 
Best regards, Sergey.

From jason_mehrens at hotmail.com  Thu Sep 13 22:26:42 2018
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 13 Sep 2018 22:26:42 +0000
Subject: RFR JDK-8209553: ExceptionInInitializerError can have a default
 detail message if the cause is given
In-Reply-To: <a7d354e2-60f5-6210-3fc0-da96deac9554@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>
 <ccc391ff-b17a-77d9-defb-8cb451fe9c0b@oracle.com>
 <CY4PR18MB132024BC98ED3BEC70BA80C5831A0@CY4PR18MB1320.namprd18.prod.outlook.com>,
 <a7d354e2-60f5-6210-3fc0-da96deac9554@oracle.com>
Message-ID: <CY4PR18MB1320ED5DDEE779DDA45E8FD3831A0@CY4PR18MB1320.namprd18.prod.outlook.com>

Looks good.  I like the change of making setCause final.

Jason
________________________________________
From: mandy chung <mandy.chung at oracle.com>
Sent: Thursday, September 13, 2018 3:50 PM
To: Jason Mehrens; 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 9/13/18 12:47 PM, Jason Mehrens wrote:

Hi Mandy,

Like in previous patches, I advocated for using 'super.getCause()' in writeObject to avoid any subclass hooking into serialization.  I even lean towards the legacy getXXX methods call super.getCause too so they are compatible with previous behavior.


Good point.  It's probably rare to have subclasses of these types and overrides getCause method.  In any case I agree it should call super.getCause for correctness.  I also added a test case with overridden getCause method.

http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.01/


Does Throwable.setCause need a more obscure name encase there are subclasses of throwable in the wild with that signature?


This is package-private method.


EIIE has double semi-colon in the constructor and PAE has a random javadoc modification.



Good catch!  It's cleaned up.

Mandy

From xueming.shen at oracle.com  Thu Sep 13 22:36:37 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 13 Sep 2018 15:36:37 -0700
Subject: JDK-8124977: deadlock between engineers? (cmdline encoding
 challenges on Windows)
In-Reply-To: <DB5PR07MB13978FACBEC0D75F530C5062E81B0@DB5PR07MB1397.eurprd07.prod.outlook.com>
References: <DB5PR07MB13978FACBEC0D75F530C5062E81B0@DB5PR07MB1397.eurprd07.prod.outlook.com>
Message-ID: <5B9AE675.1070608@oracle.com>

Anthony,

I don't see/recall there was any response to my last review comment [1]. 
The proposed
change in webrev.05 [2], in which it forces the internal system property 
sun.jnu.encoding
to be always "utf8", is incomplete and incorrect (see my comment [3] for 
why).

file.encoding: how to interpret, by default, the content in/from the 
outside of the vm, file, socket
                      for example
sun.jnu.encoding:
                      how to talk to the platform APIs, on Windows 
platform for example, how to
                      to de/encoding the bytes to/from the Win32 "A" 
version of APIs, for example
                      CreateFileA(char* fname....). It's also used to 
"interpret" the bytes in those
                      char* of the interface between jvm and libraries.
sun.stdout/err.encoding:
                      how to talk to the "console" when you output to 
the std err/out when
                      the std in/out is linked the a real console/term

So the bottom line is that you can't just simply override 
sun.jnu.encoding to utf8 on windows
before we either migrate all our "A" version win32 system call to "W" 
(do autf8->utf16) or
to put yet another layer there to convert "utf8->mb" before calling the 
"A" version win32.

An alternative is to limit the scope of the problem, to only have some 
alternative/
workaround solution for the arguments passed to Java main class. For 
example to do something
in libjli/java_md.c/CreateApplicationArgs() when decoding the char* to 
jstring via
LauncherHelper.makePaltformString(...), which uses sun.jnu.encoding now. 
(my guess is
this is where the idea of overwriting sun.jnu.encoding comes from).

Currently I don't think there is anyone from Oracle actively working on 
this issue. I'm not
sure if engineer from Microsoft is still working on it.

Thanks,
Sherman

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039070.html
[2] http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039068.html

On 9/12/18, 10:29 AM, Anthony Vanelverdinghe wrote:
> Hi
>
> What is the status of this issue [1]? It addresses some long-standing issues with Java's Unicode support on Windows and was contributed by a team of Microsoft engineers. However, it seems to have gone dormant right before the finish line, and I can't really figure out who's waiting for whom at this point.
>
> A little reconstruction from what I could find:
> In January 2015, Martin Sawicki made the initial proposal to address the cmdline encoding challenges on Windows [2]
>  From June to September, there were ongoing discussions [3][4][5][6]
> In November, this was shortly picked up again by the Oracle engineers [7]
> In January 2016, after a ping by a Microsoft engineer, the discussions restarted [8]
> In February 2016, the patch seemed nearly ready for integration, with an Oracle engineer asking whom to mention as contributors etc. [9]
> Since then, I was unable to find any messages related to this issue
>
> (Personally, I would love to see this issue progress, in order to be able to associate Java programs with file extensions on Windows. This is currently problematic, since a file containing Unicode characters will not get passed correctly as an argument to the Java program)
>
> Kind regards,
> Anthony
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8124977
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
> [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
> [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
> [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
> [7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
> [8] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
> [9] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html


From xueming.shen at oracle.com  Thu Sep 13 22:38:28 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 13 Sep 2018 15:38:28 -0700
Subject: JDK-8124977: deadlock between engineers? (cmdline encoding
 challenges on Windows)
In-Reply-To: <5B9AE675.1070608@oracle.com>
References: <DB5PR07MB13978FACBEC0D75F530C5062E81B0@DB5PR07MB1397.eurprd07.prod.outlook.com>
 <5B9AE675.1070608@oracle.com>
Message-ID: <5B9AE6E4.4080405@oracle.com>

On 9/13/18, 3:36 PM, Xueming Shen wrote:
> Anthony,
>
> I don't see/recall there was any response to my last review comment 
> [1]. The proposed
> change in webrev.05 [2], in which it forces the internal system 
> property sun.jnu.encoding
> to be always "utf8", is incomplete and incorrect (see my comment [3] 
> for why).

oops, there is one sentence is missing here :-

There are three system properties inside jvm to deal with this "native 
encoding" issue:


>
> file.encoding: how to interpret, by default, the content in/from the 
> outside of the vm, file, socket
>                      for example
> sun.jnu.encoding:
>                      how to talk to the platform APIs, on Windows 
> platform for example, how to
>                      to de/encoding the bytes to/from the Win32 "A" 
> version of APIs, for example
>                      CreateFileA(char* fname....). It's also used to 
> "interpret" the bytes in those
>                      char* of the interface between jvm and libraries.
> sun.stdout/err.encoding:
>                      how to talk to the "console" when you output to 
> the std err/out when
>                      the std in/out is linked the a real console/term
>
> So the bottom line is that you can't just simply override 
> sun.jnu.encoding to utf8 on windows
> before we either migrate all our "A" version win32 system call to "W" 
> (do autf8->utf16) or
> to put yet another layer there to convert "utf8->mb" before calling 
> the "A" version win32.
>
> An alternative is to limit the scope of the problem, to only have some 
> alternative/
> workaround solution for the arguments passed to Java main class. For 
> example to do something
> in libjli/java_md.c/CreateApplicationArgs() when decoding the char* to 
> jstring via
> LauncherHelper.makePaltformString(...), which uses sun.jnu.encoding 
> now. (my guess is
> this is where the idea of overwriting sun.jnu.encoding comes from).
>
> Currently I don't think there is anyone from Oracle actively working 
> on this issue. I'm not
> sure if engineer from Microsoft is still working on it.
>
> Thanks,
> Sherman
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039070.html
> [2] http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
> [3] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039068.html
>
> On 9/12/18, 10:29 AM, Anthony Vanelverdinghe wrote:
>> Hi
>>
>> What is the status of this issue [1]? It addresses some long-standing 
>> issues with Java's Unicode support on Windows and was contributed by 
>> a team of Microsoft engineers. However, it seems to have gone dormant 
>> right before the finish line, and I can't really figure out who's 
>> waiting for whom at this point.
>>
>> A little reconstruction from what I could find:
>> In January 2015, Martin Sawicki made the initial proposal to address 
>> the cmdline encoding challenges on Windows [2]
>>  From June to September, there were ongoing discussions [3][4][5][6]
>> In November, this was shortly picked up again by the Oracle engineers 
>> [7]
>> In January 2016, after a ping by a Microsoft engineer, the 
>> discussions restarted [8]
>> In February 2016, the patch seemed nearly ready for integration, with 
>> an Oracle engineer asking whom to mention as contributors etc. [9]
>> Since then, I was unable to find any messages related to this issue
>>
>> (Personally, I would love to see this issue progress, in order to be 
>> able to associate Java programs with file extensions on Windows. This 
>> is currently problematic, since a file containing Unicode characters 
>> will not get passed correctly as an argument to the Java program)
>>
>> Kind regards,
>> Anthony
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8124977
>> [2] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
>> [3] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
>> [4] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
>> [5] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
>> [6] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
>> [7] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
>> [8] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
>> [9] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html
>


From mark.reinhold at oracle.com  Thu Sep 13 22:58:37 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 13 Sep 2018 15:58:37 -0700 (PDT)
Subject: New candidate JEP: 343: Packaging Tool
Message-ID: <20180913225837.9A8042097B0@eggemoggin.niobe.net>

http://openjdk.java.net/jeps/343

- Mark

From ioi.lam at oracle.com  Thu Sep 13 23:06:08 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 13 Sep 2018 16:06:08 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize()
 function to handle long path on windows
In-Reply-To: <5B96BB03.3070503@oracle.com>
References: <5B96BB03.3070503@oracle.com>
Message-ID: <DFF1D488-20AC-497A-A8A8-92DD27441450@oracle.com>

Looks good. Thanks!

Ioi

> On Sep 10, 2018, at 11:42 AM, Calvin Cheung <calvin.cheung at oracle.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
> 
> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
> 
> Please review this change for handling long path specified in the -Xbootclasspath/a on windows.
> 
> Highlight of changes:
> - canonicalize_md.c
>    it makes use of the unicode version of canonicalize (wcanonicalize) if the original path is >= MAX_PATH.
> 
> - zip_util.c
>    it uses the unicode version of CreateFile (CreateFileW) if the original path is >= MAX_PATH.
> 
> - io_util_md.c
>    Since zip_util.c (libzip) calls the getPrefixed() function in canonicalize_md.c (libjava), the getPrefixed() function needs to be exported.
> 
> - java_md.h
>    The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It is because the the current usage of the canonicalize() function from vm code is to preallocate the output buffer as follows:
>            char* canonical_path = NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>            if (!get_canonical_path(path, canonical_path, JVM_MAXPATHLEN)) {
>    Also the unix version of canonicalize() function has the following check:
>            int
>           canonicalize(char *original, char *resolved, int len)
>           {
>               if (len < PATH_MAX) {
>               errno = EINVAL;
>               return -1;
>           }
>   So dynamically allocating the output buffer requires more work beyond the scope of this change.
> 
> - LongBCP.java
>    added a scenario to the test - a long path to a jar file in -Xbootclasspath/a.
> 
> Testing: tier-[1,2,3].
> 
> thanks,
> Calvin


From calvin.cheung at oracle.com  Thu Sep 13 23:11:18 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 13 Sep 2018 16:11:18 -0700
Subject: RFR(S) 8190737: use unicode version of the canonicalize() function
 to handle long path on windows
In-Reply-To: <DFF1D488-20AC-497A-A8A8-92DD27441450@oracle.com>
References: <5B96BB03.3070503@oracle.com>
 <DFF1D488-20AC-497A-A8A8-92DD27441450@oracle.com>
Message-ID: <5B9AEE96.2040209@oracle.com>

Thanks, Ioi.

Calvin

On 9/13/18, 4:06 PM, Ioi Lam wrote:
> Looks good. Thanks!
>
> Ioi
>
>> On Sep 10, 2018, at 11:42 AM, Calvin Cheung<calvin.cheung at oracle.com>  wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8190737
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
>>
>> Please review this change for handling long path specified in the -Xbootclasspath/a on windows.
>>
>> Highlight of changes:
>> - canonicalize_md.c
>>     it makes use of the unicode version of canonicalize (wcanonicalize) if the original path is>= MAX_PATH.
>>
>> - zip_util.c
>>     it uses the unicode version of CreateFile (CreateFileW) if the original path is>= MAX_PATH.
>>
>> - io_util_md.c
>>     Since zip_util.c (libzip) calls the getPrefixed() function in canonicalize_md.c (libjava), the getPrefixed() function needs to be exported.
>>
>> - java_md.h
>>     The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It is because the the current usage of the canonicalize() function from vm code is to preallocate the output buffer as follows:
>>             char* canonical_path = NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN);
>>             if (!get_canonical_path(path, canonical_path, JVM_MAXPATHLEN)) {
>>     Also the unix version of canonicalize() function has the following check:
>>             int
>>            canonicalize(char *original, char *resolved, int len)
>>            {
>>                if (len<  PATH_MAX) {
>>                errno = EINVAL;
>>                return -1;
>>            }
>>    So dynamically allocating the output buffer requires more work beyond the scope of this change.
>>
>> - LongBCP.java
>>     added a scenario to the test - a long path to a jar file in -Xbootclasspath/a.
>>
>> Testing: tier-[1,2,3].
>>
>> thanks,
>> Calvin

From erik.joelsson at oracle.com  Thu Sep 13 23:17:03 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Sep 2018 16:17:03 -0700
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
 <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
 <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>
Message-ID: <a57ea824-4b5e-d1df-48a8-95d297c83ef0@oracle.com>

I checked and the copying of java.exe was done in the now legacy jre 
installer, so from what I can tell, there is no longer a need for static 
linking.

/Erik


On 2018-09-13 09:14, Erik Joelsson wrote:
> Hello,
>
> Reading that bug, it seems the problem is when the installer copies 
> java.exe into the Windows system directory. In that case, it may not 
> have access to the msvcr re-distributables. I will try to find out if 
> our installers are still doing this.
>
> /Erik
>
>
> On 2018-09-13 06:32, Alan Bateman wrote:
>>
>>
>> On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
>>> :
>>>
>>> Apparently, someone was trying to get rid of dll dependencies from 
>>> java.exe. Why that would be desirable it does not say. Neither why 
>>> this should not apply to all other launchers. (Perhaps there were 
>>> not that many in these days?)
>>>
>>> Do anyone think this still seems relevant? Otherwise I'd like to get 
>>> rid of this hack, and link java and javaw just like all the other 
>>> launchers.
>>>
>> I don't know if it is still needed but it seems to be related to the 
>> upgrade to VC 7 and an issue related to redistribution issue of the 
>> MS runtime. JDK-6282039 and JDK-6382014 have some info on this.
>>
>> -Alan.
>


From gromero at linux.vnet.ibm.com  Thu Sep 13 23:29:53 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 13 Sep 2018 20:29:53 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
Message-ID: <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>

Hello Severin,

On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
> Hi David,
> 
> On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> Sorry I'm a bit confused now.
>>
>> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
>> HIGH. But now it will be LOW due to:
>>
>>     45 ifneq ($(FDLIBM_CFLAGS), )
>>     46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
>>
>> as those platforms will use gcc/clang with support for -ffp-contract and
>> so FDLIBM_CFLAGS will not be empty.
>>
>> ??
> 
> Correct. That was done based on Andrew Haley's comment here:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023160.html
> 
> I've done some measurements with -O2 and -O3. -O2 is sufficient for a
> 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
> the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
> sin/cos on ppc64le.
> 
> Since the difference between them were not huge, I've used -O2, a.k.a
> LOW. See also:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> 
> To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
> == -O2 on gcc arches. Does that clear things up?
> 
> FWIW, I'm happy to change it back to HIGH if there are concerns. See
> also Gustavo's reply here for some more data points:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023193.html

I'm wondering why the possible issue of using -O3 on fdlibm would not affect
other parts of the JVM code (like the Opto code in libjvm.so) that afaics
are also built using -O3. Also, the gap of 1.05 for sin/cos, for instance,
still sounds like a regression to me.

Maybe a better approach to this would be to figure out a way to test -O3 and
-O2 with the real world case in which -O3 can have a bad impact. I'm not
sure if SPECjbb would qualify for that.


Best regards,
Gustavo

> Thanks,
> Severin
> 
>> David
>>
>> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
>>> Hi Erik,
>>>
>>> Thanks for the review!
>>>
>>> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>>>> Hello Severin,
>>>>
>>>> Even if using the macro, I still think you need to add a condition on
>>>> the compiler types where the switch can be reasonably expected to exist.
>>>
>>> How about this?
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
>>>
>>> Thanks,
>>> Severin
>>>
>>>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>>>>
>>>>> OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>>>
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
>>>>>
>>>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>>>> here (-O2 is sufficient it seems):
>>>>>
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
>>>>>
>>>>> More thoughts?
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>>> [1] https://github.com/gromero/strictmath/
>>>>>
>>>>
>>>>
> 


From stuart.marks at oracle.com  Thu Sep 13 23:52:16 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 13 Sep 2018 16:52:16 -0700
Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning"
 class can be dropped
In-Reply-To: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
Message-ID: <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>

I'd guess that security-dev would have reviewers for the change to 
default.policy. Cc'd.

s'marks

On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk12.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
> 
> The client code has a "com.sun.awt.SecurityWarning" class which at some point in 
> the past, JDK 6u10, was used as a kind of "public" API.
> 
> During development of jdk9 it was considered that this API is not supported and 
> may be removed in the future: JDK-8051640.
> In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) and can 
> be dropped in 12.
> 
> In the fix these things were removed:
>  ?- com/sun/awt/SecurityWarning.java
>  ?- The test for SecurityWarning class
>  ?- Test groups, because SecurityWarning is the latest class in "com/sun/awt" 
> package
>  ?- The reference to "com/sun/awt" in the "default.policy"
> 
> (cc) core-libs-dev:
> I am not sure who is responsible to review the change in "default.policy".
> 
> 

From igor.ignatyev at oracle.com  Fri Sep 14 00:07:58 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 13 Sep 2018 17:07:58 -0700
Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils
Message-ID: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> 478 lines changed: 3 ins; 319 del; 156 mod; 

Hi all,

could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class?

webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
testing: tier[1-3] + :jdk_svc,:jdk_security_infra
JBS: https://bugs.openjdk.java.net/browse/JDK-8210732

Thanks,
-- Igor

From jcbeyler at google.com  Fri Sep 14 00:37:25 2018
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 13 Sep 2018 17:37:25 -0700
Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils
In-Reply-To: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>
References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>
Message-ID: <CAF9BGBz-aARog3ZwyNeZmqtHyNi7XeZhmJeebMfBKKYx6rNXfQ@mail.gmail.com>

Hi Igor,

Looks good to me!
Jc

On Thu, Sep 13, 2018 at 5:08 PM Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> > 478 lines changed: 3 ins; 319 del; 156 mod;
>
> Hi all,
>
> could you please review the next clean up in jdk testlibrary which removes
> jdk.testlibrary.Utils class?
>
> webrev:
> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> testing: tier[1-3] + :jdk_svc,:jdk_security_infra
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210732
>
> Thanks,
> -- Igor



-- 

Thanks,
Jc

From mandy.chung at oracle.com  Fri Sep 14 02:20:17 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 13 Sep 2018 19:20:17 -0700
Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning"
 class can be dropped
In-Reply-To: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
Message-ID: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>


On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk12.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>

Thus change looks okay to me.? This class is not exported
and so I have updated the CSR of "Implementation" scope rather
than JDK.

Mandy

> The client code has a "com.sun.awt.SecurityWarning" class which at 
> some point in the past, JDK 6u10, was used as a kind of "public" API.
>
> During development of jdk9 it was considered that this API is not 
> supported and may be removed in the future: JDK-8051640.
> In jdk11 this class was marked as "forRemoval = true" (see 
> JDK-8205588) and can be dropped in 12.
>
> In the fix these things were removed:
> ?- com/sun/awt/SecurityWarning.java
> ?- The test for SecurityWarning class
> ?- Test groups, because SecurityWarning is the latest class in 
> "com/sun/awt" package
> ?- The reference to "com/sun/awt" in the "default.policy"
>
> (cc) core-libs-dev:
> I am not sure who is responsible to review the change in 
> "default.policy".
>
>


From huizhe.wang at oracle.com  Fri Sep 14 03:13:48 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 13 Sep 2018 20:13:48 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
Message-ID: <5B9B276C.2010609@oracle.com>

Thanks Daniel.

I changed the return of writeUTF16Surrogate so that it is clearer within 
writeUTF16Surrogate when an additional index increment is needed. Other 
corresponding changes are in ToHTMLStream and ToTextStream where similar 
calls to the method are made. It's been an issue in some part of JAXP 
impl where error or warning messages are printed out to the console 
(e.g. JDK-8000621). But I kept it as is in ToTextStream for this patch.

webrev01:
http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev01/

Best,
Joe

On 9/13/18, 2:23 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> On 13/09/2018 00:25, Lance Andersen wrote:
>> Hi Joe,
>>
>> The change  seems reasonable
>
> Agreed. However the following condition in ToStream::handleEscaping
> is a bit cryptic:
>
> 1155             if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
> 1156                 i++ ; // process two input characters
> 1157             }
>
> could the comment be fleshed out to explain it?
>
> I suspect that: `(ihs && (i + 1 < end))` means that
> `writeUTF16Surrogate(c, ch, i, end);` has written the two surrogate, in
> which case i should be incremented in order to skip the low surrogate
> which has just been written.
>
> I am not sure what `(ils && i != 0)` means, though...
>
> best regards
>
> -- daniel
>
>>
>>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Please review a patch for a situation where a surrogate pair is at 
>>> the edge of a buffer. What the existing impl did was to report it as 
>>> an error. This patch fixes it by caching the high surrogate and 
>>> prints it out along with the low surrogate. Similar issue exists 
>>> also in the CDATA section and is fixed in this patch. The CDATA impl 
>>> had a couple of bugs where an indent could be written inside the 
>>> CDATA and an unicode character written in between two CDATA 
>>> sections. Both are fixed in this patch.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>>
>>> 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 xu.y.yin at oracle.com  Fri Sep 14 03:42:38 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 14 Sep 2018 11:42:38 +0800
Subject: [12] RFR 8210695: Create test to cover JDK-8205330
 InitialDirContext ctor sometimes throws NPE if the server has sent a
 disconnection
In-Reply-To: <02180a46-41cd-3e66-59e0-3738fa4180ae@oracle.com>
References: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>
 <02180a46-41cd-3e66-59e0-3738fa4180ae@oracle.com>
Message-ID: <C4515F6A-A9A2-4984-83ED-F88B0D13225E@oracle.com>

Hi, Daniel

Thank you for the reviewing and comments, inline and update webrev as below, thanks

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

> On 13 Sep 2018, at 5:43 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> Thanks a lot for writing this test!
> 
>  60         serverSocket = new ServerSocket(0);
>  69         env.put(Context.PROVIDER_URL, String.format("ldap://localhost:%d/",
> 
> For robustness of the test I would suggest using
> InetAddress.getLoopbackAddress() explicitly, to
> avoid having the dummy server listen on all interfaces.
> Listening on all interfaces has proved to be a source of
> intermittent failures in the past, possibly due
> to different port reuse strategies at OS level.

Sure, fixed, thanks

> 
>  88                     System.out.println("(" + count + "/" + REPEAT_COUNT
>  89                             + ") It's ok to get NamingException: " + ne);
>  90                     // for debug
>  91                     ne.printStackTrace();
> 
> I think it would be better in that case to print the stactrace on
> stdout (i.e. use ne.printStackTrace(System.out)), since that
> exception is expected and not considered as an error.

Yep, fixed as you suggested. My original though is that the stack trace maybe too verbose if most of runs hit NamingException, leave it to stderr may make the log more readable, but yes, the exception is expected and not considered as error as you commented. Anyway, we could adjust it later if necessary.

Regards,
Chris

> 
> best regards,
> 
> -- daniel
> 
> 
> On 13/09/2018 07:59, Chris Yin wrote:
>> Please have a review for below new added test to cover JDK-8205330, thanks
>> This test used dummy ldap server to simulate the scenario to send ?Notice of Disconnection? after binding, it will repeat InitialDirContext() for 1000 times (normally the NPE bug should be hit less than 100 times run, but just in case), test failed with NPE if without JDK-8205330 fix change and passed after the fix.
>> I put this test under test/jdk/com/sun/jndi/ldap/ since the bug root cause is from com.sun.jndi.ldap.LdapClient, feel free to let me know if it should be moved to other suitable folder.
>> bug: https://bugs.openjdk.java.net/browse/JDK-8210695
>> webrev: http://cr.openjdk.java.net/~xyin/8210695/webrev.00/
>> Regards,
>> Chris
> 


From jai.forums2013 at gmail.com  Fri Sep 14 05:36:27 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 14 Sep 2018 11:06:27 +0530
Subject: Source file launcher - Handling of pre-compiled classes of the source
 file
Message-ID: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>

Please consider this trivial code C.java:

public class C {
?? ?public static void main(String[] args) throws Exception {
?? ??? ?System.out.println("main() execution started");
?? ?}
}


> ls
C.java

Similar to a previous discussion[1] while doing random testing, I ended
up compiling C.java explicitly using javac:

> javac C.java
> ls
C.java C.class

and then at a later date tried to use the source file launcher feature
of Java 11 (without realizing C.class was already present in the dir):

> java C.java

This threw the error:

error: class found on application class path: C

Although the error isn't that clear for the reason I note in [2], having
run into this before, I was aware what this meant and deleted the
C.class and moved on. The important part here is that the source
launcher noticed this condition and aborted even before it auto
compiled(?) and launched and executed the main() of the program.

Now consider a slight modification to that source file:

public class C {
??? public static void main(String[] args) throws Exception {
??? ??? System.out.println("main() execution started");
??? ??? final B b = new B();
??? ??? System.out.println("Done");
??? }

??? private static class B {

??? }
}

Again at some point I compiled this explicitly using javac, so my
directory is (among other things):

> ls
C$B.class??? C.class??? ??? C.java

Then ran the source file launcher feature:

> java C.java
error: class found on application class path: C

As expected, ran into the same previous error. As before, in order to
move on, deleted C.class:

> rm C.class

but forgot to delete the nested static class that belonged to it. So the
directory now contained:

> ls
C$B.class??? C.java

Now used the source launcher feature again:

> java C.java

This time it failed with:

main() execution started
Exception in thread "main" java.lang.IllegalAccessError: failed to
access class C$B from class C (C$B is in unnamed module of loader 'app';
C is in unnamed module of loader
com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
??? at C.main(C.java:4)

The error message isn't clear to pinpoint the issue, but at least the
reference to MemoryClassLoader was a hint that was enough for me to
understand where to look. It did take me a few minutes to realize that
C$B.class was lying around which I needed to remove too.

However, IMO, the important part here is that unlike in the first case
where the program itself wasn't launched and instead was aborted early,
in this case the program did get executed (notice the System.out.println
"main() execution started" message that got printed) and failed at runtime.

Would it be possible to make these two behaviours consistent and detect
such cases and abort early here too? Or would that add too much
complexity to this feature?

Finally, any thoughts on the error messages for this feature to make it
a bit easier in terms of debugging (classloading) issues like these?

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html

-Jaikiran


From Alan.Bateman at oracle.com  Fri Sep 14 06:53:27 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Sep 2018 07:53:27 +0100
Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils
In-Reply-To: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>
References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>
Message-ID: <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com>



On 14/09/2018 01:07, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
>> 478 lines changed: 3 ins; 319 del; 156 mod;
> Hi all,
>
> could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class?
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
> testing: tier[1-3] + :jdk_svc,:jdk_security_infra
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210732
>
Looks good and only a few remaining classes in testlibrary to move.

-Alan

From magnus.ihse.bursie at oracle.com  Fri Sep 14 07:22:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 14 Sep 2018 09:22:25 +0200
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <a57ea824-4b5e-d1df-48a8-95d297c83ef0@oracle.com>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
 <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
 <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>
 <a57ea824-4b5e-d1df-48a8-95d297c83ef0@oracle.com>
Message-ID: <e94a94ef-cf8f-ed1f-ff00-f858b3ef6c5b@oracle.com>


On 2018-09-14 01:17, Erik Joelsson wrote:
> I checked and the copying of java.exe was done in the now legacy jre 
> installer, so from what I can tell, there is no longer a need for 
> static linking.

Sounds good. I agree with your reasoning, it seems the main concern was 
the copy to the system directory. A second point was raised in private, 
that the old system of letting the java launcher select another version 
to launch, could be behind this. Neither this system is kept anymore.

Thanks for all input!

/Magnus

>
> /Erik
>
>
> On 2018-09-13 09:14, Erik Joelsson wrote:
>> Hello,
>>
>> Reading that bug, it seems the problem is when the installer copies 
>> java.exe into the Windows system directory. In that case, it may not 
>> have access to the msvcr re-distributables. I will try to find out if 
>> our installers are still doing this.
>>
>> /Erik
>>
>>
>> On 2018-09-13 06:32, Alan Bateman wrote:
>>>
>>>
>>> On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
>>>> :
>>>>
>>>> Apparently, someone was trying to get rid of dll dependencies from 
>>>> java.exe. Why that would be desirable it does not say. Neither why 
>>>> this should not apply to all other launchers. (Perhaps there were 
>>>> not that many in these days?)
>>>>
>>>> Do anyone think this still seems relevant? Otherwise I'd like to 
>>>> get rid of this hack, and link java and javaw just like all the 
>>>> other launchers.
>>>>
>>> I don't know if it is still needed but it seems to be related to the 
>>> upgrade to VC 7 and an issue related to redistribution issue of the 
>>> MS runtime. JDK-6282039 and JDK-6382014 have some info on this.
>>>
>>> -Alan.
>>
>


From peter.levart at gmail.com  Fri Sep 14 07:33:55 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 14 Sep 2018 09:33:55 +0200
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
Message-ID: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>

Hi Jaikiran,

Forwarding to compiler-dev as the core of source file launcher feature 
is produced there...

The check for main class is performed after compilation (which actually 
produces the main class name).

I think it would be possible to check for all classes compiled from the 
source file after compilation without to much complication. The 
compilation produces classes and stores them into a Map<String, byte[]>. 
The keySet() of that map is a Set of compiled class names. Each of them 
could be tested via .getResource() invoked upon the application class 
loader. The error could even point to the URL of the conflicting class 
file that way...

Regards, Peter

On 09/14/2018 07:36 AM, Jaikiran Pai wrote:
> Please consider this trivial code C.java:
>
> public class C {
>  ?? ?public static void main(String[] args) throws Exception {
>  ?? ??? ?System.out.println("main() execution started");
>  ?? ?}
> }
>
>
>> ls
> C.java
>
> Similar to a previous discussion[1] while doing random testing, I ended
> up compiling C.java explicitly using javac:
>
>> javac C.java
>> ls
> C.java C.class
>
> and then at a later date tried to use the source file launcher feature
> of Java 11 (without realizing C.class was already present in the dir):
>
>> java C.java
> This threw the error:
>
> error: class found on application class path: C
>
> Although the error isn't that clear for the reason I note in [2], having
> run into this before, I was aware what this meant and deleted the
> C.class and moved on. The important part here is that the source
> launcher noticed this condition and aborted even before it auto
> compiled(?) and launched and executed the main() of the program.
>
> Now consider a slight modification to that source file:
>
> public class C {
>  ??? public static void main(String[] args) throws Exception {
>  ??? ??? System.out.println("main() execution started");
>  ??? ??? final B b = new B();
>  ??? ??? System.out.println("Done");
>  ??? }
>
>  ??? private static class B {
>
>  ??? }
> }
>
> Again at some point I compiled this explicitly using javac, so my
> directory is (among other things):
>
>> ls
> C$B.class??? C.class??? ??? C.java
>
> Then ran the source file launcher feature:
>
>> java C.java
> error: class found on application class path: C
>
> As expected, ran into the same previous error. As before, in order to
> move on, deleted C.class:
>
>> rm C.class
> but forgot to delete the nested static class that belonged to it. So the
> directory now contained:
>
>> ls
> C$B.class??? C.java
>
> Now used the source launcher feature again:
>
>> java C.java
> This time it failed with:
>
> main() execution started
> Exception in thread "main" java.lang.IllegalAccessError: failed to
> access class C$B from class C (C$B is in unnamed module of loader 'app';
> C is in unnamed module of loader
> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
>  ??? at C.main(C.java:4)
>
> The error message isn't clear to pinpoint the issue, but at least the
> reference to MemoryClassLoader was a hint that was enough for me to
> understand where to look. It did take me a few minutes to realize that
> C$B.class was lying around which I needed to remove too.
>
> However, IMO, the important part here is that unlike in the first case
> where the program itself wasn't launched and instead was aborted early,
> in this case the program did get executed (notice the System.out.println
> "main() execution started" message that got printed) and failed at runtime.
>
> Would it be possible to make these two behaviours consistent and detect
> such cases and abort early here too? Or would that add too much
> complexity to this feature?
>
> Finally, any thoughts on the error messages for this feature to make it
> a bit easier in terms of debugging (classloading) issues like these?
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html
>
> -Jaikiran
>


From amaembo at gmail.com  Fri Sep 14 08:41:53 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 14 Sep 2018 15:41:53 +0700
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: <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>

Hello, Stuart and Peter!

Thank you for valuable comments. I updated the webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/

1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
"-ing" suffix shall present and I agree. Hopefully it's final name.
2. I updated the spec as Stuart suggested.

No changes in implementation since r3 revision. Please check.

With best regards,
Tagir Valeev.


On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> 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 markus.gronlund at oracle.com  Fri Sep 14 08:50:29 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 14 Sep 2018 01:50:29 -0700 (PDT)
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <e94a94ef-cf8f-ed1f-ff00-f858b3ef6c5b@oracle.com>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
 <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
 <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>
 <a57ea824-4b5e-d1df-48a8-95d297c83ef0@oracle.com>
 <e94a94ef-cf8f-ed1f-ff00-f858b3ef6c5b@oracle.com>
Message-ID: <64244b15-2091-498b-b4c3-76cef3d5ab42@default>

Hi Magnus, Erik and Alan,

Came to think of this issue in relation to this discussion:

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

It might provide some additional information, especially since it describes an issue we recently ran into that was related to  static linking.

Thanks
Markus



-----Original Message-----
From: Magnus Ihse Bursie 
Sent: den 14 september 2018 09:22
To: Erik Joelsson <erik.joelsson at oracle.com>; Alan Bateman <alan.bateman at oracle.com>; core-libs-dev at openjdk.java.net
Cc: build-dev <build-dev at openjdk.java.net>
Subject: Re: Why static_jli for java/javaw on Windows?


On 2018-09-14 01:17, Erik Joelsson wrote:
> I checked and the copying of java.exe was done in the now legacy jre 
> installer, so from what I can tell, there is no longer a need for 
> static linking.

Sounds good. I agree with your reasoning, it seems the main concern was the copy to the system directory. A second point was raised in private, that the old system of letting the java launcher select another version to launch, could be behind this. Neither this system is kept anymore.

Thanks for all input!

/Magnus

>
> /Erik
>
>
> On 2018-09-13 09:14, Erik Joelsson wrote:
>> Hello,
>>
>> Reading that bug, it seems the problem is when the installer copies 
>> java.exe into the Windows system directory. In that case, it may not 
>> have access to the msvcr re-distributables. I will try to find out if 
>> our installers are still doing this.
>>
>> /Erik
>>
>>
>> On 2018-09-13 06:32, Alan Bateman wrote:
>>>
>>>
>>> On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
>>>> :
>>>>
>>>> Apparently, someone was trying to get rid of dll dependencies from 
>>>> java.exe. Why that would be desirable it does not say. Neither why 
>>>> this should not apply to all other launchers. (Perhaps there were 
>>>> not that many in these days?)
>>>>
>>>> Do anyone think this still seems relevant? Otherwise I'd like to 
>>>> get rid of this hack, and link java and javaw just like all the 
>>>> other launchers.
>>>>
>>> I don't know if it is still needed but it seems to be related to the 
>>> upgrade to VC 7 and an issue related to redistribution issue of the 
>>> MS runtime. JDK-6282039 and JDK-6382014 have some info on this.
>>>
>>> -Alan.
>>
>


From sgehwolf at redhat.com  Fri Sep 14 09:22:47 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 14 Sep 2018 11:22:47 +0200
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>
Message-ID: <766c6c6b22b7f28fcc367bc4b8f230afb5f7595c.camel@redhat.com>

Hi,

On Thu, 2018-09-13 at 20:29 -0300, Gustavo Romero wrote:
> Hello Severin,
> 
> On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
> > Hi David,
> > 
> > On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > Sorry I'm a bit confused now.
> > > 
> > > Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
> > > HIGH. But now it will be LOW due to:
> > > 
> > >     45 ifneq ($(FDLIBM_CFLAGS), )
> > >     46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> > > 
> > > as those platforms will use gcc/clang with support for -ffp-contract and
> > > so FDLIBM_CFLAGS will not be empty.
> > > 
> > > ??
> > 
> > Correct. That was done based on Andrew Haley's comment here:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023160.html
> > 
> > I've done some measurements with -O2 and -O3. -O2 is sufficient for a
> > 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
> > the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
> > sin/cos on ppc64le.
> > 
> > Since the difference between them were not huge, I've used -O2, a.k.a
> > LOW. See also:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> > 
> > To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
> > == -O2 on gcc arches. Does that clear things up?
> > 
> > FWIW, I'm happy to change it back to HIGH if there are concerns. See
> > also Gustavo's reply here for some more data points:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023193.html
> 
> I'm wondering why the possible issue of using -O3 on fdlibm would not affect
> other parts of the JVM code (like the Opto code in libjvm.so) that afaics
> are also built using -O3. Also, the gap of 1.05 for sin/cos, for instance,
> still sounds like a regression to me.

Fair enough. I'm not picky which of the two opt levels to go with as
long as we can agree on one. To me, both -O2 and -O3 seem reasonable
with -ffp-contract=off.

> Maybe a better approach to this would be to figure out a way to test -O3 and
> -O2 with the real world case in which -O3 can have a bad impact. I'm not
> sure if SPECjbb would qualify for that.

I'll let Andrew Haley comment on this one.

In my opinion, no *single* benchmark qualifies as "real-world-program"
as it would inadvertently look at one specific aspect. With hat being
said, any such benchmark would have to explicitly use StrictMath over
Math, no? Otherwise intrinsics would kick in. Is that likely? Also, as
Joe Darcy pointed out, some are now implemented in Java.

Cheers,
Severin

> 
> > Thanks,
> > Severin
> > 
> > > David
> > > 
> > > On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
> > > > Hi Erik,
> > > > 
> > > > Thanks for the review!
> > > > 
> > > > On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
> > > > > Hello Severin,
> > > > > 
> > > > > Even if using the macro, I still think you need to add a condition on
> > > > > the compiler types where the switch can be reasonably expected to exist.
> > > > 
> > > > How about this?
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.05/
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > On 2018-09-11 05:02, Severin Gehwolf wrote:
> > > > > > On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> > > > > > > I see. I was not aware of that issue, but we clearly need to file a bug
> > > > > > > for it and fix it. In this case I think it's fine to us the macro however.
> > > > > > 
> > > > > > OK. Update webrev, which now uses FLAGS_COMPILER_CHECK_ARGUMENTS.
> > > > > > 
> > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.04/
> > > > > > 
> > > > > > Micro-benchmark results from running [1] for x86_64 and ppc64le are
> > > > > > here (-O2 is sufficient it seems):
> > > > > > 
> > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
> > > > > > 
> > > > > > More thoughts?
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > > [1] https://github.com/gromero/strictmath/
> > > > > > 
> > > > > 
> > > > > 
> 
> 


From peter.levart at gmail.com  Fri Sep 14 09:23:49 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 14 Sep 2018 11:23:49 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
Message-ID: <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>

Hi Tagir,

I like duplexing more than teeingAndThen. If consensus can be 
established about the name, I think you will then want to update the CSR 
draft to reflect new name. Then we'll kindly ask Stuart if he has any 
more advice before submitting the CSR...

Regards, Peter

On 09/14/2018 10:41 AM, Tagir Valeev wrote:
> Hello, Stuart and Peter!
>
> Thank you for valuable comments. I updated the webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
>
> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
> "-ing" suffix shall present and I agree. Hopefully it's final name.
> 2. I updated the spec as Stuart suggested.
>
> No changes in implementation since r3 revision. Please check.
>
> With best regards,
> Tagir Valeev.
>
>
> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>> 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 magnus.ihse.bursie at oracle.com  Fri Sep 14 09:36:33 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 14 Sep 2018 11:36:33 +0200
Subject: Why static_jli for java/javaw on Windows?
In-Reply-To: <64244b15-2091-498b-b4c3-76cef3d5ab42@default>
References: <04a57cbc-0807-a721-15ec-a5757ac49d76@oracle.com>
 <f894a22a-edbd-8948-f9ad-d458704997ac@oracle.com>
 <7c8cce78-b028-cb7c-d6d9-6e4bc4f94829@oracle.com>
 <a57ea824-4b5e-d1df-48a8-95d297c83ef0@oracle.com>
 <e94a94ef-cf8f-ed1f-ff00-f858b3ef6c5b@oracle.com>
 <64244b15-2091-498b-b4c3-76cef3d5ab42@default>
Message-ID: <d552156b-1460-b786-20ab-7943e5572162@oracle.com>

On 2018-09-14 10:50, Markus Gronlund wrote:
> Hi Magnus, Erik and Alan,
>
> Came to think of this issue in relation to this discussion:
>
> https://bugs.openjdk.java.net/browse/JDK-8207139
>
> It might provide some additional information, especially since it describes an issue we recently ran into that was related to  static linking.
Thanks Markus!

Just to be clear that I read this correctly: Changing libjli from static 
to dynamic did not introduce a problem for you, instead it actually 
*solved* a problem? (If so, that's even more argument to skip the static 
linking)

/Magnus

>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: Magnus Ihse Bursie
> Sent: den 14 september 2018 09:22
> To: Erik Joelsson <erik.joelsson at oracle.com>; Alan Bateman <alan.bateman at oracle.com>; core-libs-dev at openjdk.java.net
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: Why static_jli for java/javaw on Windows?
>
>
> On 2018-09-14 01:17, Erik Joelsson wrote:
>> I checked and the copying of java.exe was done in the now legacy jre
>> installer, so from what I can tell, there is no longer a need for
>> static linking.
> Sounds good. I agree with your reasoning, it seems the main concern was the copy to the system directory. A second point was raised in private, that the old system of letting the java launcher select another version to launch, could be behind this. Neither this system is kept anymore.
>
> Thanks for all input!
>
> /Magnus
>
>> /Erik
>>
>>
>> On 2018-09-13 09:14, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Reading that bug, it seems the problem is when the installer copies
>>> java.exe into the Windows system directory. In that case, it may not
>>> have access to the msvcr re-distributables. I will try to find out if
>>> our installers are still doing this.
>>>
>>> /Erik
>>>
>>>
>>> On 2018-09-13 06:32, Alan Bateman wrote:
>>>>
>>>> On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
>>>>> :
>>>>>
>>>>> Apparently, someone was trying to get rid of dll dependencies from
>>>>> java.exe. Why that would be desirable it does not say. Neither why
>>>>> this should not apply to all other launchers. (Perhaps there were
>>>>> not that many in these days?)
>>>>>
>>>>> Do anyone think this still seems relevant? Otherwise I'd like to
>>>>> get rid of this hack, and link java and javaw just like all the
>>>>> other launchers.
>>>>>
>>>> I don't know if it is still needed but it seems to be related to the
>>>> upgrade to VC 7 and an issue related to redistribution issue of the
>>>> MS runtime. JDK-6282039 and JDK-6382014 have some info on this.
>>>>
>>>> -Alan.


From daniel.fuchs at oracle.com  Fri Sep 14 10:00:08 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Sep 2018 11:00:08 +0100
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <5B9B276C.2010609@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
Message-ID: <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>

Hi Joe,

Thanks for doing that - it's a far better solution.

ToHTMLStream.java:

1432    // move the index if the surrogate pair has been written.
1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
1434        i++;
1435    }

shouldn't this be:

1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
             if (Encodings.isHighUTF16Surrogate(ch)) {
                 // two input characters processed, increase
                 // the index again.
                 i++;
             }

IIUC you only want to increase the index if the ch was the
high surrogate and the function has advanced to the low
surrogate?

I mean - a codepoint could have been returned if ch was the
low surrogate, and in that case you don't want to increase
the index twice as only one character has been consumed.

I guess there's the same issue in ToStream.java at lines
1154-1156 and in ToTextStream.java at line 303...

Or am I missing something?

best regards,

-- daniel


On 14/09/2018 04:13, Joe Wang wrote:
> Thanks Daniel.
> 
> I changed the return of writeUTF16Surrogate so that it is clearer within 
> writeUTF16Surrogate when an additional index increment is needed. Other 
> corresponding changes are in ToHTMLStream and ToTextStream where similar 
> calls to the method are made. It's been an issue in some part of JAXP 
> impl where error or warning messages are printed out to the console 
> (e.g. JDK-8000621). But I kept it as is in ToTextStream for this patch.
> 
> webrev01:
> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev01/
> 
> Best,
> Joe
> 
> On 9/13/18, 2:23 AM, Daniel Fuchs wrote:
>> Hi Joe,
>>
>> On 13/09/2018 00:25, Lance Andersen wrote:
>>> Hi Joe,
>>>
>>> The change? seems reasonable
>>
>> Agreed. However the following condition in ToStream::handleEscaping
>> is a bit cryptic:
>>
>> 1155???????????? if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
>> 1156???????????????? i++ ; // process two input characters
>> 1157???????????? }
>>
>> could the comment be fleshed out to explain it?
>>
>> I suspect that: `(ihs && (i + 1 < end))` means that
>> `writeUTF16Surrogate(c, ch, i, end);` has written the two surrogate, in
>> which case i should be incremented in order to skip the low surrogate
>> which has just been written.
>>
>> I am not sure what `(ils && i != 0)` means, though...
>>
>> best regards
>>
>> -- daniel
>>
>>>
>>>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review a patch for a situation where a surrogate pair is at 
>>>> the edge of a buffer. What the existing impl did was to report it as 
>>>> an error. This patch fixes it by caching the high surrogate and 
>>>> prints it out along with the low surrogate. Similar issue exists 
>>>> also in the CDATA section and is fixed in this patch. The CDATA impl 
>>>> had a couple of bugs where an indent could be written inside the 
>>>> CDATA and an unicode character written in between two CDATA 
>>>> sections. Both are fixed in this patch.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>>>
>>>> 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 goetz.lindenmaier at sap.com  Fri Sep 14 10:12:20 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 14 Sep 2018 10:12:20 +0000
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <c4fd8b42307f5a72e076a24dcb916b7da9bfefce.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>
Message-ID: <712db2594acf4b5b82fcb3fe7c19042c@sap.com>

Hi,

We are only talking about reducing O3 to O2 for the compilation 
step of fdlibm, right?
As I know, this is being replaced by Java coding, anyways.
Therefore I don't have a strong opinion for any of the 
choices.

Best regards,
  Goetz.

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Gustavo Romero
> Sent: Freitag, 14. September 2018 01:30
> To: Severin Gehwolf <sgehwolf at redhat.com>; David Holmes
> <david.holmes at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com>;
> build-dev <build-dev at openjdk.java.net>; core-libs-dev <core-libs-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-
> optimized compilation
> 
> Hello Severin,
> 
> On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
> > Hi David,
> >
> > On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> >> Hi Severin,
> >>
> >> Sorry I'm a bit confused now.
> >>
> >> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
> >> HIGH. But now it will be LOW due to:
> >>
> >>     45 ifneq ($(FDLIBM_CFLAGS), )
> >>     46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
> >>
> >> as those platforms will use gcc/clang with support for -ffp-contract and
> >> so FDLIBM_CFLAGS will not be empty.
> >>
> >> ??
> >
> > Correct. That was done based on Andrew Haley's comment here:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-
> September/023160.html
> >
> > I've done some measurements with -O2 and -O3. -O2 is sufficient for a
> > 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
> > the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
> > sin/cos on ppc64le.
> >
> > Since the difference between them were not huge, I've used -O2, a.k.a
> > LOW. See also:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/microbenchmarks_results/
> >
> > To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
> > == -O2 on gcc arches. Does that clear things up?
> >
> > FWIW, I'm happy to change it back to HIGH if there are concerns. See
> > also Gustavo's reply here for some more data points:
> > http://mail.openjdk.java.net/pipermail/build-dev/2018-
> September/023193.html
> 
> I'm wondering why the possible issue of using -O3 on fdlibm would not affect
> other parts of the JVM code (like the Opto code in libjvm.so) that afaics
> are also built using -O3. Also, the gap of 1.05 for sin/cos, for instance,
> still sounds like a regression to me.
> 
> Maybe a better approach to this would be to figure out a way to test -O3 and
> -O2 with the real world case in which -O3 can have a bad impact. I'm not
> sure if SPECjbb would qualify for that.
> 
> 
> Best regards,
> Gustavo
> 
> > Thanks,
> > Severin
> >
> >> David
> >>
> >> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
> >>> Hi Erik,
> >>>
> >>> Thanks for the review!
> >>>
> >>> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
> >>>> Hello Severin,
> >>>>
> >>>> Even if using the macro, I still think you need to add a condition on
> >>>> the compiler types where the switch can be reasonably expected to
> exist.
> >>>
> >>> How about this?
> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/webrev.05/
> >>>
> >>> Thanks,
> >>> Severin
> >>>
> >>>> On 2018-09-11 05:02, Severin Gehwolf wrote:
> >>>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
> >>>>>> I see. I was not aware of that issue, but we clearly need to file a bug
> >>>>>> for it and fix it. In this case I think it's fine to us the macro however.
> >>>>>
> >>>>> OK. Update webrev, which now uses
> FLAGS_COMPILER_CHECK_ARGUMENTS.
> >>>>>
> >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/webrev.04/
> >>>>>
> >>>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
> >>>>> here (-O2 is sufficient it seems):
> >>>>>
> >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210416/microbenchmarks_results/
> >>>>>
> >>>>> More thoughts?
> >>>>>
> >>>>> Thanks,
> >>>>> Severin
> >>>>>
> >>>>> [1] https://github.com/gromero/strictmath/
> >>>>>
> >>>>
> >>>>
> >


From daniel.fuchs at oracle.com  Fri Sep 14 10:19:07 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Sep 2018 11:19:07 +0100
Subject: [12] RFR 8210695: Create test to cover JDK-8205330
 InitialDirContext ctor sometimes throws NPE if the server has sent a
 disconnection
In-Reply-To: <C4515F6A-A9A2-4984-83ED-F88B0D13225E@oracle.com>
References: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>
 <02180a46-41cd-3e66-59e0-3738fa4180ae@oracle.com>
 <C4515F6A-A9A2-4984-83ED-F88B0D13225E@oracle.com>
Message-ID: <0b1d63ee-4b6d-1f07-a1ea-dc6a557c5e04@oracle.com>

Hi Chris,

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

Looks good to me.

 > Yep, fixed as you suggested. My original though is that the stack 
trace maybe too verbose if most of runs hit NamingException, leave it to 
stderr may make the log more readable, but yes, the exception is 
expected and not considered as error as you commented. Anyway, we could 
adjust it later if necessary.

An alternative then would be to print an additional message on
stderr - something like:

   89                 } catch (NamingException ne) {
   90                     System.out.println("(" + count + "/" + 
REPEAT_COUNT
   91                             + ") It's ok to get NamingException: " 
+ ne);
   92                     // for debug
                          System.err.println("Caught expected exception: 
" + ne);
   93                     ne.printStackTrace();

If you decide to go this way instead then no need for an additional
review...

best regards,

-- daniel



On 14/09/2018 04:42, Chris Yin wrote:
> Hi, Daniel
> 
> Thank you for the reviewing and comments, inline and update webrev as below, thanks
> 
> http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
> 
>> On 13 Sep 2018, at 5:43 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Thanks a lot for writing this test!
>>
>>   60         serverSocket = new ServerSocket(0);
>>   69         env.put(Context.PROVIDER_URL, String.format("ldap://localhost:%d/",
>>
>> For robustness of the test I would suggest using
>> InetAddress.getLoopbackAddress() explicitly, to
>> avoid having the dummy server listen on all interfaces.
>> Listening on all interfaces has proved to be a source of
>> intermittent failures in the past, possibly due
>> to different port reuse strategies at OS level.
> 
> Sure, fixed, thanks
> 
>>
>>   88                     System.out.println("(" + count + "/" + REPEAT_COUNT
>>   89                             + ") It's ok to get NamingException: " + ne);
>>   90                     // for debug
>>   91                     ne.printStackTrace();
>>
>> I think it would be better in that case to print the stactrace on
>> stdout (i.e. use ne.printStackTrace(System.out)), since that
>> exception is expected and not considered as an error.
> 
> Yep, fixed as you suggested. My original though is that the stack trace maybe too verbose if most of runs hit NamingException, leave it to stderr may make the log more readable, but yes, the exception is expected and not considered as error as you commented. Anyway, we could adjust it later if necessary.
> 
> Regards,
> Chris
> 
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 13/09/2018 07:59, Chris Yin wrote:
>>> Please have a review for below new added test to cover JDK-8205330, thanks
>>> This test used dummy ldap server to simulate the scenario to send ?Notice of Disconnection? after binding, it will repeat InitialDirContext() for 1000 times (normally the NPE bug should be hit less than 100 times run, but just in case), test failed with NPE if without JDK-8205330 fix change and passed after the fix.
>>> I put this test under test/jdk/com/sun/jndi/ldap/ since the bug root cause is from com.sun.jndi.ldap.LdapClient, feel free to let me know if it should be moved to other suitable folder.
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210695
>>> webrev: http://cr.openjdk.java.net/~xyin/8210695/webrev.00/
>>> Regards,
>>> Chris
>>
> 


From forax at univ-mlv.fr  Fri Sep 14 10:23:43 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Sep 2018 12:23:43 +0200 (CEST)
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
Message-ID: <571221170.307852.1536920623247.JavaMail.zimbra@u-pem.fr>

I'm neither Stuart nor Peter but this looks good to me.

R?mi

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> ?: "Stuart Marks" <stuart.marks at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 14 Septembre 2018 10:41:53
> Objet: Re: RFR: JDK-8205461 Create Collector which merges results of two other collectors

> Hello, Stuart and Peter!
> 
> Thank you for valuable comments. I updated the webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
> 
> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
> "-ing" suffix shall present and I agree. Hopefully it's final name.
> 2. I updated the spec as Stuart suggested.
> 
> No changes in implementation since r3 revision. Please check.
> 
> With best regards,
> Tagir Valeev.
> 
> 
> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> 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 daniel.fuchs at oracle.com  Fri Sep 14 11:01:09 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Sep 2018 12:01:09 +0100
Subject: Review Request JDK-8210721: Replace legacy serial exception field
 with Throwable::cause
In-Reply-To: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
References: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
Message-ID: <a5c6cc8c-c6a0-5780-df46-f4bc7a4bcabc@oracle.com>

Hi Mandy,

Looks good to me as well.

If a JDK 12 exception is deserialized by an earlier version of
the JDK, then the deserialized exception will have both its
cause field and custom exception field set to the cause
(instead of having the cause field null and the custom field
carrying the cause), but I believe that's benign.

Nit: PrivilegedActionException.java

   75      *Memory

is missing a space after the *.

Obviously no need for another webrev, and no need for a new
fix if you pushed already...

best regards,

-- daniel


On 13/09/2018 19:44, mandy chung wrote:
> A few exception classes such as ExceptionInInitializerError, 
> InvocationTargetException,
> etc were defined prior to the exception chaining facility and provides 
> the API to get
> the cause of the exception. These classes keep its legacy serial field e.g.
> ExceptionInInitializerError::exception to get the serialization to work 
> on older JDK version.
> 
> During the review of JDK-8209553 [1], Peter and Joe suggest to remove 
> this legacy
> serial field and implement the serialization using 
> serialPersistentFields, readObject
> and writeObject.?? It turns out that these redundant fields were removed 
> when the
> exception chaining support was initially implemented but it got reverted 
> to fix
> JDK-4385429 since Throwable::setCause rejects any further change as
> Throwable::cause has been initialized to null.
> 
> This patch removes these legacy serial field and stores the cause in 
> Throwable::cause.
> It's essentially a redo for the fix for JDK-4385429.
> 
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/
> 
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html 
> 


From aleksej.efimov at oracle.com  Fri Sep 14 12:50:41 2018
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 14 Sep 2018 13:50:41 +0100
Subject: [8u-dev] Request for review and approval for 8193830: Xalan Update:
 Xalan Java 2.7.2
Message-ID: <afc9c8f9-1b28-d4a1-5224-9d2d752b7279@oracle.com>

Hello,

Can I, please, have an approval to backport JDK-8193830 to jdk8u-dev?

Webrev:
http://cr.openjdk.java.net/~aefimov/8193830
JBS:
https://bugs.openjdk.java.net/browse/JDK-8193830
JDK11 review:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051230.html
JDK11 changeset:
http://hg.openjdk.java.net/jdk/jdk/rev/0474300affbd

The JAXP source changes part is identical (after reshuffling) to 
original JDK11 fix.

The differences are in the regression test:
a) Location of the regression test
b) Address missing jaxp.library.JAXPTestUtilities in JDK8

Therefore, the test change requires review too.

With Best Regards,
Aleksei

From rachna.goel at oracle.com  Fri Sep 14 12:54:57 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 14 Sep 2018 18:24:57 +0530
Subject: [12] RFR:8210490:TimeZone.getDisplayName given Locale.US doesn't
 always honor the Locale
Message-ID: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>

Hi,

Kindly review fix to JDK-8210490.

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

Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/

This is a regression caused by JDK-8202537, where for timezones such as 
Etc/GMT-5, display names got formatted according to default locale.

Fix is to specify locale, which was specified in 
timezone.getDisplayName() method.

-- 
Thanks,
Rachna


From gromero at linux.vnet.ibm.com  Fri Sep 14 13:28:28 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Fri, 14 Sep 2018 10:28:28 -0300
Subject: RFR: 8210416: [linux] Poor StrictMath performance due to
 non-optimized compilation
In-Reply-To: <712db2594acf4b5b82fcb3fe7c19042c@sap.com>
References: <b18dea0e47d5abfeb8a0164a4a5b171953b72bbc.camel@redhat.com>
 <d15193bb-544e-a1a2-63c9-67d128768993@oracle.com>
 <4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com>
 <dc2b248d-24e1-2f51-a934-64d78dc975fb@oracle.com>
 <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com>
 <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com>
 <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com>
 <bd941c8130dbc7eaa823ce544ac9efb1b4a9b1ea.camel@redhat.com>
 <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com>
 <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com>
 <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com>
 <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com>
 <b99c944b-620b-7115-830e-0d75188941db@oracle.com>
 <d4188a317f35bd44bf0d84514288577c5a2e844a.camel@redhat.com>
 <d99cde73-0295-30ee-30e7-d65410ab9dad@oracle.com>
 <73829c9f640099d7b4e7dcd6c074a79aabe49cd5.camel@redhat.com>
 <4156bad0-3ca7-2167-850d-3aed6f4b5cd3@linux.vnet.ibm.com>
 <712db2594acf4b5b82fcb3fe7c19042c@sap.com>
Message-ID: <1245b773-e434-f296-3428-0374e532da4c@linux.vnet.ibm.com>

Hi Goetz and Severin,

On 09/14/2018 07:12 AM, Lindenmaier, Goetz wrote:
> Hi,
> 
> We are only talking about reducing O3 to O2 for the compilation
> step of fdlibm, right?

Yes.


> As I know, this is being replaced by Java coding, anyways.
> Therefore I don't have a strong opinion for any of the
> choices.

I totally agree with Goetz considering OpenJDK 12 and 11u. I was actually more
concerned about a possible future backport of that change, for instance: it gets
into 8u, but Java implementations never get. Maybe I forgot to mention my
concern about a 8u backport earlier.

Severin, anyway, as Goetz is also fine with either option, I'm fine with what
you and Andrew decide as the best option.

Thanks bearing with the discussion on ppc64.


Best regards,
Gustavo

> Best regards,
>    Goetz.
> 
>> -----Original Message-----
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
>> Of Gustavo Romero
>> Sent: Freitag, 14. September 2018 01:30
>> To: Severin Gehwolf <sgehwolf at redhat.com>; David Holmes
>> <david.holmes at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com>;
>> build-dev <build-dev at openjdk.java.net>; core-libs-dev <core-libs-
>> dev at openjdk.java.net>
>> Subject: Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-
>> optimized compilation
>>
>> Hello Severin,
>>
>> On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
>>> Hi David,
>>>
>>> On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
>>>> Hi Severin,
>>>>
>>>> Sorry I'm a bit confused now.
>>>>
>>>> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
>>>> HIGH. But now it will be LOW due to:
>>>>
>>>>      45 ifneq ($(FDLIBM_CFLAGS), )
>>>>      46   BUILD_LIBFDLIBM_OPTIMIZATION := LOW
>>>>
>>>> as those platforms will use gcc/clang with support for -ffp-contract and
>>>> so FDLIBM_CFLAGS will not be empty.
>>>>
>>>> ??
>>>
>>> Correct. That was done based on Andrew Haley's comment here:
>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-
>> September/023160.html
>>>
>>> I've done some measurements with -O2 and -O3. -O2 is sufficient for a
>>> 2.75 speedup for sin/cos on ppc64le as compared to the -O0 baseline. On
>>> the other hand the speedup of -O3 as compared to -O2 is only 1.05 for
>>> sin/cos on ppc64le.
>>>
>>> Since the difference between them were not huge, I've used -O2, a.k.a
>>> LOW. See also:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
>> 8210416/microbenchmarks_results/
>>>
>>> To me it seems -O2 is sufficiently good. Note that HIGH == -O3 and LOW
>>> == -O2 on gcc arches. Does that clear things up?
>>>
>>> FWIW, I'm happy to change it back to HIGH if there are concerns. See
>>> also Gustavo's reply here for some more data points:
>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-
>> September/023193.html
>>
>> I'm wondering why the possible issue of using -O3 on fdlibm would not affect
>> other parts of the JVM code (like the Opto code in libjvm.so) that afaics
>> are also built using -O3. Also, the gap of 1.05 for sin/cos, for instance,
>> still sounds like a regression to me.
>>
>> Maybe a better approach to this would be to figure out a way to test -O3 and
>> -O2 with the real world case in which -O3 can have a bad impact. I'm not
>> sure if SPECjbb would qualify for that.
>>
>>
>> Best regards,
>> Gustavo
>>
>>> Thanks,
>>> Severin
>>>
>>>> David
>>>>
>>>> On 12/09/2018 2:14 AM, Severin Gehwolf wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Thanks for the review!
>>>>>
>>>>> On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
>>>>>> Hello Severin,
>>>>>>
>>>>>> Even if using the macro, I still think you need to add a condition on
>>>>>> the compiler types where the switch can be reasonably expected to
>> exist.
>>>>>
>>>>> How about this?
>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
>> 8210416/webrev.05/
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>>>> On 2018-09-11 05:02, Severin Gehwolf wrote:
>>>>>>> On Mon, 2018-09-10 at 09:29 -0700, Erik Joelsson wrote:
>>>>>>>> I see. I was not aware of that issue, but we clearly need to file a bug
>>>>>>>> for it and fix it. In this case I think it's fine to us the macro however.
>>>>>>>
>>>>>>> OK. Update webrev, which now uses
>> FLAGS_COMPILER_CHECK_ARGUMENTS.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
>> 8210416/webrev.04/
>>>>>>>
>>>>>>> Micro-benchmark results from running [1] for x86_64 and ppc64le are
>>>>>>> here (-O2 is sufficient it seems):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
>> 8210416/microbenchmarks_results/
>>>>>>>
>>>>>>> More thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Severin
>>>>>>>
>>>>>>> [1] https://github.com/gromero/strictmath/
>>>>>>>
>>>>>>
>>>>>>
>>>
> 


From t.linkowski at gmail.com  Fri Sep 14 13:43:23 2018
From: t.linkowski at gmail.com (Tomasz Linkowski)
Date: Fri, 14 Sep 2018 15:43:23 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <829381c3-80c8-1fa5-de8d-a8364b8c6405@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
Message-ID: <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>

 Hi,

I'd like to remind three little things to which there was no response
(AFAIK):

1) Brian Goetz' suggestion of changing "? extends R" into "R":
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054947.html

2) Stuart Marks' suggestion about renaming "c1" and "c2" to "downstream1"
and "downstream2":
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html

3) my suggestion about renaming "merger" to "biFinisher" because "merger"
means BinaryOperator everywhere else:
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055235.html


As to the name, I still think a name related to a well-understood concept
(like the composite pattern [1]) would be better. Note that "composite" is
also a verb [2], but "Collectors.compositing" looks a bit strange.
"Collectors.composing" seems much better to me, but - as far as I
understand - there was some concern that the users could misunderstand it
as element-wise composition, is that right?

Regards,
Tomasz Linkowski

[1] https://en.wikipedia.org/wiki/Composite_pattern
[2] https://en.wiktionary.org/wiki/composite#Verb



On Fri, Sep 14, 2018 at 11:23 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> Hi Tagir,
>
> I like duplexing more than teeingAndThen. If consensus can be established
> about the name, I think you will then want to update the CSR draft to
> reflect new name. Then we'll kindly ask Stuart if he has any more advice
> before submitting the CSR...
>
> Regards, Peter
>
>
> On 09/14/2018 10:41 AM, Tagir Valeev wrote:
>
>> Hello, Stuart and Peter!
>>
>> Thank you for valuable comments. I updated the webrev:
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
>>
>> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
>> "-ing" suffix shall present and I agree. Hopefully it's final name.
>> 2. I updated the spec as Stuart suggested.
>>
>> No changes in implementation since r3 revision. Please check.
>>
>> With best regards,
>> Tagir Valeev.
>>
>>
>> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com>
>> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>>
>


-- 
Pozdrawiam,
Tomasz Linkowski

From huizhe.wang at oracle.com  Fri Sep 14 17:08:52 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 14 Sep 2018 10:08:52 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
 <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
Message-ID: <5B9BEB24.5040605@oracle.com>

Hi Daniel,

The additional advance is made when the pair has already been written, 
which is indicated by the return value of writeUTF16Surrogate being >= 
0*. Encodings.isHighUTF16Surrogate(ch) therefore would be redundant.

* Note that the return value is: -1 when nothing is written, 0 when the 
pair is written, so the condition of >= 0 means no matter there is a 
codepoint value or not, the index increment as long as the pair is 
written (the low surrogate is consumed).

Best,
Joe

On 9/14/18, 3:00 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> Thanks for doing that - it's a far better solution.
>
> ToHTMLStream.java:
>
> 1432    // move the index if the surrogate pair has been written.
> 1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
> 1434        i++;
> 1435    }
>
> shouldn't this be:
>
> 1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
>             if (Encodings.isHighUTF16Surrogate(ch)) {
>                 // two input characters processed, increase
>                 // the index again.
>                 i++;
>             }
>
> IIUC you only want to increase the index if the ch was the
> high surrogate and the function has advanced to the low
> surrogate?
>
> I mean - a codepoint could have been returned if ch was the
> low surrogate, and in that case you don't want to increase
> the index twice as only one character has been consumed.
>
> I guess there's the same issue in ToStream.java at lines
> 1154-1156 and in ToTextStream.java at line 303...
>
> Or am I missing something?
>
> best regards,
>
> -- daniel
>
>
> On 14/09/2018 04:13, Joe Wang wrote:
>> Thanks Daniel.
>>
>> I changed the return of writeUTF16Surrogate so that it is clearer 
>> within writeUTF16Surrogate when an additional index increment is 
>> needed. Other corresponding changes are in ToHTMLStream and 
>> ToTextStream where similar calls to the method are made. It's been an 
>> issue in some part of JAXP impl where error or warning messages are 
>> printed out to the console (e.g. JDK-8000621). But I kept it as is in 
>> ToTextStream for this patch.
>>
>> webrev01:
>> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev01/
>>
>> Best,
>> Joe
>>
>> On 9/13/18, 2:23 AM, Daniel Fuchs wrote:
>>> Hi Joe,
>>>
>>> On 13/09/2018 00:25, Lance Andersen wrote:
>>>> Hi Joe,
>>>>
>>>> The change  seems reasonable
>>>
>>> Agreed. However the following condition in ToStream::handleEscaping
>>> is a bit cryptic:
>>>
>>> 1155             if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
>>> 1156                 i++ ; // process two input characters
>>> 1157             }
>>>
>>> could the comment be fleshed out to explain it?
>>>
>>> I suspect that: `(ihs && (i + 1 < end))` means that
>>> `writeUTF16Surrogate(c, ch, i, end);` has written the two surrogate, in
>>> which case i should be incremented in order to skip the low surrogate
>>> which has just been written.
>>>
>>> I am not sure what `(ils && i != 0)` means, though...
>>>
>>> best regards
>>>
>>> -- daniel
>>>
>>>>
>>>>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review a patch for a situation where a surrogate pair is at 
>>>>> the edge of a buffer. What the existing impl did was to report it 
>>>>> as an error. This patch fixes it by caching the high surrogate and 
>>>>> prints it out along with the low surrogate. Similar issue exists 
>>>>> also in the CDATA section and is fixed in this patch. The CDATA 
>>>>> impl had a couple of bugs where an indent could be written inside 
>>>>> the CDATA and an unicode character written in between two CDATA 
>>>>> sections. Both are fixed in this patch.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>>>>
>>>>> 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 stuart.marks at oracle.com  Fri Sep 14 17:09:04 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 14 Sep 2018 10:09:04 -0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
Message-ID: <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>

Hi Tagir, thanks for the update.

Also thanks Tomasz for keeping everybody honest on the open issues.

First, naming. I think "duplex" as the root word wins! Using "duplexing" to 
conform to many of other collectors is fine; so, "duplexing" is good.

Unfortunately "duplex" is not really a verb. For some reason "duplexing" sounds 
OK. This probably follows in the long tradition of the tech industry's "verbing" 
of nouns and adjectives. However, I can't quite bring myself to recommend using 
this in the javadoc summary sentence, e.g.,

    Returns a {@code Collector} that duplexes stream elements to two downstream
    collectors.

Ugh. I think the current summary sentence is fine

    Returns a {@code Collector} that is a composite of two downstream collectors.

even though it uses "composite" which is not the name of this collector. But I 
think it's a more descriptive term and it reads more smoothly.

Turning to the issues mentioned by Tomasz:

> 1) Brian Goetz' suggestion of changing "? extends R" into "R":
> ? - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054947.html
Yes, I think this should be done.
> 2) Stuart Marks' suggestion about renaming "c1" and "c2" to "downstream1" and 
> "downstream2":
> ? - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html
Yes. It's a small thing, but the parameter names do appear in the javadoc. The 
text refers to "downstream" collectors, and naming the parameters "downstream" 
strengthens the association to the text. Otherwise, the reader has to think 
"what are c1 and c2? Oh, they're the downstream collectors."
> 3) my suggestion about renaming "merger" to "biFinisher" because "merger" 
> means BinaryOperator everywhere else:
> ? - 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055235.html
I'm ok with "merger". I don't feel that "merge" has a strong implication that 
the result must be the same type as the two inputs. I'm ok with the notion of 
"merge" taking two inputs (which might be of different types) and producing a 
single output (which might be a different type from either input). The 
difficulty with "biFinisher" is that it doesn't seem to imply "take two things 
and produce one". A finisher takes one input and produces one output, so would a 
"biFinisher" take two inputs and produce two outputs?
> As to the name, I still think a name related to a well-understood concept 
> (like the composite pattern [1]) would be better. Note that "composite" is 
> also a verb [2], but "Collectors.compositing" looks a bit strange. 
> "Collectors.composing" seems much better to me, but - as far as I understand - 
> there was some concern that the users could misunderstand it as element-wise 
> composition, is that right?
The difficulty I have with "compose" and "composition" is that with function 
composition, one function is applied, and the second function is applied to the 
result of the first. Of course that isn't what happens here. The notion of 
"duplexing" is that things are happening side-by-side, which applies well here, 
I think.

**

Tagir, overall, looks good! Let me know when you've finished updating the CSR.

Thanks,

s'marks
>
> Regards,
> Tomasz Linkowski
>
> [1] https://en.wikipedia.org/wiki/Composite_pattern
> [2] https://en.wiktionary.org/wiki/composite#Verb
>
>
>
> On Fri, Sep 14, 2018 at 11:23 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>     Hi Tagir,
>
>     I like duplexing more than teeingAndThen. If consensus can be established
>     about the name, I think you will then want to update the CSR draft to
>     reflect new name. Then we'll kindly ask Stuart if he has any more advice
>     before submitting the CSR...
>
>     Regards, Peter
>
>
>     On 09/14/2018 10:41 AM, Tagir Valeev wrote:
>
>         Hello, Stuart and Peter!
>
>         Thank you for valuable comments. I updated the webrev:
>         http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
>         <http://cr.openjdk.java.net/%7Etvaleev/webrev/8205461/r4/>
>
>         1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
>         "-ing" suffix shall present and I agree. Hopefully it's final name.
>         2. I updated the spec as Stuart suggested.
>
>         No changes in implementation since r3 revision. Please check.
>
>         With best regards,
>         Tagir Valeev.
>
>
>         On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com
>         <mailto:stuart.marks at oracle.com>> wrote:
>
>             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
>                 <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 <mailto: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/
>                     <http://cr.openjdk.java.net/%7Etvaleev/webrev/8205461/r3/>
>                     Also copyright year is updated
>
>                     With best regards,
>                     Tagir Valeev
>
>
>
>
>
>
> -- 
> Pozdrawiam,
> Tomasz Linkowski


From seth.lytle at gmail.com  Fri Sep 14 17:14:52 2018
From: seth.lytle at gmail.com (seth lytle)
Date: Fri, 14 Sep 2018 13:14:52 -0400
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
Message-ID: <CAJtn+Adnk0sg31g7Cuw8aTV9zsXKZAFZQNa8mODvazOTbhUgdw@mail.gmail.com>

this behavior of throwing an error if the class is found twice on the
classpath strikes me as unusual - afaik, in all other cases, java is fine
with finding multiple implementations on the classpath and uses the first
found (similar to the unix path, which also allows overriding by providing
an explicit path) and this is really one of the powerful features of java -
allowing you to swap out one class for another seamlessly. and for rapid
prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs
much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and doubly
so for mvnDebug










On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> Hi Jaikiran,
>
> Forwarding to compiler-dev as the core of source file launcher feature is
> produced there...
>
> The check for main class is performed after compilation (which actually
> produces the main class name).
>
> I think it would be possible to check for all classes compiled from the
> source file after compilation without to much complication. The compilation
> produces classes and stores them into a Map<String, byte[]>. The keySet()
> of that map is a Set of compiled class names. Each of them could be tested
> via .getResource() invoked upon the application class loader. The error
> could even point to the URL of the conflicting class file that way...
>
> Regards, Peter
>
>
> On 09/14/2018 07:36 AM, Jaikiran Pai wrote:
>
> Please consider this trivial code C.java:
>
> public class C {
>     public static void main(String[] args) throws Exception {
>         System.out.println("main() execution started");
>     }
> }
>
>
>
> ls
>
> C.java
>
> Similar to a previous discussion[1] while doing random testing, I ended
> up compiling C.java explicitly using javac:
>
>
> javac C.java
> ls
>
> C.java C.class
>
> and then at a later date tried to use the source file launcher feature
> of Java 11 (without realizing C.class was already present in the dir):
>
>
> java C.java
>
> This threw the error:
>
> error: class found on application class path: C
>
> Although the error isn't that clear for the reason I note in [2], having
> run into this before, I was aware what this meant and deleted the
> C.class and moved on. The important part here is that the source
> launcher noticed this condition and aborted even before it auto
> compiled(?) and launched and executed the main() of the program.
>
> Now consider a slight modification to that source file:
>
> public class C {
>     public static void main(String[] args) throws Exception {
>         System.out.println("main() execution started");
>         final B b = new B();
>         System.out.println("Done");
>     }
>
>     private static class B {
>
>     }
> }
>
> Again at some point I compiled this explicitly using javac, so my
> directory is (among other things):
>
>
> ls
>
> C$B.class    C.class        C.java
>
> Then ran the source file launcher feature:
>
>
> java C.java
>
> error: class found on application class path: C
>
> As expected, ran into the same previous error. As before, in order to
> move on, deleted C.class:
>
>
> rm C.class
>
> but forgot to delete the nested static class that belonged to it. So the
> directory now contained:
>
>
> ls
>
> C$B.class    C.java
>
> Now used the source launcher feature again:
>
>
> java C.java
>
> This time it failed with:
>
> main() execution started
> Exception in thread "main" java.lang.IllegalAccessError: failed to
> access class C$B from class C (C$B is in unnamed module of loader 'app';
> C is in unnamed module of loader
> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
>     at C.main(C.java:4)
>
> The error message isn't clear to pinpoint the issue, but at least the
> reference to MemoryClassLoader was a hint that was enough for me to
> understand where to look. It did take me a few minutes to realize that
> C$B.class was lying around which I needed to remove too.
>
> However, IMO, the important part here is that unlike in the first case
> where the program itself wasn't launched and instead was aborted early,
> in this case the program did get executed (notice the System.out.println
> "main() execution started" message that got printed) and failed at runtime.
>
> Would it be possible to make these two behaviours consistent and detect
> such cases and abort early here too? Or would that add too much
> complexity to this feature?
>
> Finally, any thoughts on the error messages for this feature to make it
> a bit easier in terms of debugging (classloading) issues like these?
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html
>
> -Jaikiran
>
>
>
>

From anthonyv.be at outlook.com  Fri Sep 14 17:16:51 2018
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Fri, 14 Sep 2018 17:16:51 +0000
Subject: JDK-8124977: deadlock between engineers? (cmdline encoding
 challenges on Windows)
In-Reply-To: <5B9AE6E4.4080405@oracle.com>
References: <DB5PR07MB13978FACBEC0D75F530C5062E81B0@DB5PR07MB1397.eurprd07.prod.outlook.com>
 <5B9AE675.1070608@oracle.com>,<5B9AE6E4.4080405@oracle.com>
Message-ID: <DB5PR07MB1397A045A40036EF52747DEBE8190@DB5PR07MB1397.eurprd07.prod.outlook.com>

Thanks for the status update and insightful details, Sherman, they?re much appreciated.



Kind regards,

Anthony





________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Xueming Shen <xueming.shen at oracle.com>
Sent: Friday, September 14, 2018 12:38:28 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)

On 9/13/18, 3:36 PM, Xueming Shen wrote:
> Anthony,
>
> I don't see/recall there was any response to my last review comment
> [1]. The proposed
> change in webrev.05 [2], in which it forces the internal system
> property sun.jnu.encoding
> to be always "utf8", is incomplete and incorrect (see my comment [3]
> for why).

oops, there is one sentence is missing here :-

There are three system properties inside jvm to deal with this "native
encoding" issue:


>
> file.encoding: how to interpret, by default, the content in/from the
> outside of the vm, file, socket
>                      for example
> sun.jnu.encoding:
>                      how to talk to the platform APIs, on Windows
> platform for example, how to
>                      to de/encoding the bytes to/from the Win32 "A"
> version of APIs, for example
>                      CreateFileA(char* fname....). It's also used to
> "interpret" the bytes in those
>                      char* of the interface between jvm and libraries.
> sun.stdout/err.encoding:
>                      how to talk to the "console" when you output to
> the std err/out when
>                      the std in/out is linked the a real console/term
>
> So the bottom line is that you can't just simply override
> sun.jnu.encoding to utf8 on windows
> before we either migrate all our "A" version win32 system call to "W"
> (do autf8->utf16) or
> to put yet another layer there to convert "utf8->mb" before calling
> the "A" version win32.
>
> An alternative is to limit the scope of the problem, to only have some
> alternative/
> workaround solution for the arguments passed to Java main class. For
> example to do something
> in libjli/java_md.c/CreateApplicationArgs() when decoding the char* to
> jstring via
> LauncherHelper.makePaltformString(...), which uses sun.jnu.encoding
> now. (my guess is
> this is where the idea of overwriting sun.jnu.encoding comes from).
>
> Currently I don't think there is anyone from Oracle actively working
> on this issue. I'm not
> sure if engineer from Microsoft is still working on it.
>
> Thanks,
> Sherman
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039070.html
> [2] http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
> [3]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039068.html
>
> On 9/12/18, 10:29 AM, Anthony Vanelverdinghe wrote:
>> Hi
>>
>> What is the status of this issue [1]? It addresses some long-standing
>> issues with Java's Unicode support on Windows and was contributed by
>> a team of Microsoft engineers. However, it seems to have gone dormant
>> right before the finish line, and I can't really figure out who's
>> waiting for whom at this point.
>>
>> A little reconstruction from what I could find:
>> In January 2015, Martin Sawicki made the initial proposal to address
>> the cmdline encoding challenges on Windows [2]
>>  From June to September, there were ongoing discussions [3][4][5][6]
>> In November, this was shortly picked up again by the Oracle engineers
>> [7]
>> In January 2016, after a ping by a Microsoft engineer, the
>> discussions restarted [8]
>> In February 2016, the patch seemed nearly ready for integration, with
>> an Oracle engineer asking whom to mention as contributors etc. [9]
>> Since then, I was unable to find any messages related to this issue
>>
>> (Personally, I would love to see this issue progress, in order to be
>> able to associate Java programs with file extensions on Windows. This
>> is currently problematic, since a file containing Unicode characters
>> will not get passed correctly as an argument to the Java program)
>>
>> Kind regards,
>> Anthony
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8124977
>> [2]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.html
>> [3]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html
>> [4]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html
>> [5]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html
>> [6]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.html
>> [7]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.html
>> [8]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.html
>> [9]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.html
>


From mandy.chung at oracle.com  Fri Sep 14 17:46:46 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 14 Sep 2018 10:46:46 -0700
Subject: Review Request JDK-8210721: Replace legacy serial exception field
 with Throwable::cause
In-Reply-To: <a5c6cc8c-c6a0-5780-df46-f4bc7a4bcabc@oracle.com>
References: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
 <a5c6cc8c-c6a0-5780-df46-f4bc7a4bcabc@oracle.com>
Message-ID: <0fe7b6aa-6e7c-8620-3263-3f513ae08af6@oracle.com>


On 9/14/18 4:01 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> Looks good to me as well.
>
> If a JDK 12 exception is deserialized by an earlier version of
> the JDK, then the deserialized exception will have both its
> cause field and custom exception field set to the cause
> (instead of having the cause field null and the custom field
> carrying the cause), but I believe that's benign.
>

yes that's the implementation of the older JDK and the getCause method 
returns the private exception field.
> Nit: PrivilegedActionException.java
>
> ? 75????? *Memory
>
> is missing a space after the *.
>

Jason also caught this accidental change in a different thread [1] and also
suggests to call super.getCause since getCause is not final and may be
overridden.? The updated webrev is:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.01/

Thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055421.html
> Obviously no need for another webrev, and no need for a new
> fix if you pushed already...
>
> best regards,
>
> -- daniel
>
>
> On 13/09/2018 19:44, mandy chung wrote:
>> A few exception classes such as ExceptionInInitializerError, 
>> InvocationTargetException,
>> etc were defined prior to the exception chaining facility and 
>> provides the API to get
>> the cause of the exception. These classes keep its legacy serial 
>> field e.g.
>> ExceptionInInitializerError::exception to get the serialization to 
>> work on older JDK version.
>>
>> During the review of JDK-8209553 [1], Peter and Joe suggest to remove 
>> this legacy
>> serial field and implement the serialization using 
>> serialPersistentFields, readObject
>> and writeObject.?? It turns out that these redundant fields were 
>> removed when the
>> exception chaining support was initially implemented but it got 
>> reverted to fix
>> JDK-4385429 since Throwable::setCause rejects any further change as
>> Throwable::cause has been initialized to null.
>>
>> This patch removes these legacy serial field and stores the cause in 
>> Throwable::cause.
>> It's essentially a redo for the fix for JDK-4385429.
>>
>> webrev:
>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/
>>
>> Mandy
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html 
>>
>


From jonathan.gibbons at oracle.com  Fri Sep 14 17:49:24 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 14 Sep 2018 10:49:24 -0700
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <CAJtn+Adnk0sg31g7Cuw8aTV9zsXKZAFZQNa8mODvazOTbhUgdw@mail.gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <CAJtn+Adnk0sg31g7Cuw8aTV9zsXKZAFZQNa8mODvazOTbhUgdw@mail.gmail.com>
Message-ID: <5B9BF4A4.5040605@oracle.com>

Seth,

The reason for reporting an error is to prevent the "wrong" class being 
used!

-- Jon

On 09/14/2018 10:14 AM, seth lytle wrote:
> this behavior of throwing an error if the class is found twice on the
> classpath strikes me as unusual - afaik, in all other cases, java is fine
> with finding multiple implementations on the classpath and uses the first
> found (similar to the unix path, which also allows overriding by providing
> an explicit path) and this is really one of the powerful features of java -
> allowing you to swap out one class for another seamlessly. and for rapid
> prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs
> much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and doubly
> so for mvnDebug
>
>
>
>
>
>
>
>
>
>
> On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
>> Hi Jaikiran,
>>
>> Forwarding to compiler-dev as the core of source file launcher feature is
>> produced there...
>>
>> The check for main class is performed after compilation (which actually
>> produces the main class name).
>>
>> I think it would be possible to check for all classes compiled from the
>> source file after compilation without to much complication. The compilation
>> produces classes and stores them into a Map<String, byte[]>. The keySet()
>> of that map is a Set of compiled class names. Each of them could be tested
>> via .getResource() invoked upon the application class loader. The error
>> could even point to the URL of the conflicting class file that way...
>>
>> Regards, Peter
>>
>>
>> On 09/14/2018 07:36 AM, Jaikiran Pai wrote:
>>
>> Please consider this trivial code C.java:
>>
>> public class C {
>>      public static void main(String[] args) throws Exception {
>>          System.out.println("main() execution started");
>>      }
>> }
>>
>>
>>
>> ls
>>
>> C.java
>>
>> Similar to a previous discussion[1] while doing random testing, I ended
>> up compiling C.java explicitly using javac:
>>
>>
>> javac C.java
>> ls
>>
>> C.java C.class
>>
>> and then at a later date tried to use the source file launcher feature
>> of Java 11 (without realizing C.class was already present in the dir):
>>
>>
>> java C.java
>>
>> This threw the error:
>>
>> error: class found on application class path: C
>>
>> Although the error isn't that clear for the reason I note in [2], having
>> run into this before, I was aware what this meant and deleted the
>> C.class and moved on. The important part here is that the source
>> launcher noticed this condition and aborted even before it auto
>> compiled(?) and launched and executed the main() of the program.
>>
>> Now consider a slight modification to that source file:
>>
>> public class C {
>>      public static void main(String[] args) throws Exception {
>>          System.out.println("main() execution started");
>>          final B b = new B();
>>          System.out.println("Done");
>>      }
>>
>>      private static class B {
>>
>>      }
>> }
>>
>> Again at some point I compiled this explicitly using javac, so my
>> directory is (among other things):
>>
>>
>> ls
>>
>> C$B.class    C.class        C.java
>>
>> Then ran the source file launcher feature:
>>
>>
>> java C.java
>>
>> error: class found on application class path: C
>>
>> As expected, ran into the same previous error. As before, in order to
>> move on, deleted C.class:
>>
>>
>> rm C.class
>>
>> but forgot to delete the nested static class that belonged to it. So the
>> directory now contained:
>>
>>
>> ls
>>
>> C$B.class    C.java
>>
>> Now used the source launcher feature again:
>>
>>
>> java C.java
>>
>> This time it failed with:
>>
>> main() execution started
>> Exception in thread "main" java.lang.IllegalAccessError: failed to
>> access class C$B from class C (C$B is in unnamed module of loader 'app';
>> C is in unnamed module of loader
>> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
>>      at C.main(C.java:4)
>>
>> The error message isn't clear to pinpoint the issue, but at least the
>> reference to MemoryClassLoader was a hint that was enough for me to
>> understand where to look. It did take me a few minutes to realize that
>> C$B.class was lying around which I needed to remove too.
>>
>> However, IMO, the important part here is that unlike in the first case
>> where the program itself wasn't launched and instead was aborted early,
>> in this case the program did get executed (notice the System.out.println
>> "main() execution started" message that got printed) and failed at runtime.
>>
>> Would it be possible to make these two behaviours consistent and detect
>> such cases and abort early here too? Or would that add too much
>> complexity to this feature?
>>
>> Finally, any thoughts on the error messages for this feature to make it
>> a bit easier in terms of debugging (classloading) issues like these?
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
>> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html
>>
>> -Jaikiran
>>
>>
>>
>>


From Alan.Bateman at oracle.com  Fri Sep 14 17:52:06 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Sep 2018 18:52:06 +0100
Subject: 8210496: Improve filtering for classes with security sensitive fields
Message-ID: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>

Core reflection has a filtering mechanism to hide a number of fields 
that are critical to security or the integrity of the runtime. It's a 
bit of a band aid but it helps to reduce hacking on fields such as 
java.lang.System.security and java.lang.Class.classLoder. I'd like to 
extend the filters to hide a few additional fields from 
integrity-sensitive (and non-serializable) classes in java.lang.reflect 
and java.lang.invoke. There are of course a number of nasty hacks around 
that might break due to this but these hacks would be broken anyway with 
simple rename or other innocent refactoring (we had some of this during 
JDK 11 when Mandy fixed JDK-8202113 for example).

The webrev with the changes is here:
 ?? https://bugs.openjdk.java.net/browse/JDK-8210496

Mandy has already reviewed the CSR [1].

-Alan

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

From Alan.Bateman at oracle.com  Fri Sep 14 17:57:50 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Sep 2018 18:57:50 +0100
Subject: 8210496: Improve filtering for classes with security sensitive
 fields
In-Reply-To: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
References: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
Message-ID: <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>



On 14/09/2018 18:52, Alan Bateman wrote:
> Core reflection has a filtering mechanism to hide a number of fields 
> that are critical to security or the integrity of the runtime. It's a 
> bit of a band aid but it helps to reduce hacking on fields such as 
> java.lang.System.security and java.lang.Class.classLoder. I'd like to 
> extend the filters to hide a few additional fields from 
> integrity-sensitive (and non-serializable) classes in 
> java.lang.reflect and java.lang.invoke. There are of course a number 
> of nasty hacks around that might break due to this but these hacks 
> would be broken anyway with simple rename or other innocent 
> refactoring (we had some of this during JDK 11 when Mandy fixed 
> JDK-8202113 for example).
>
> The webrev with the changes is here:
> ?? https://bugs.openjdk.java.net/browse/JDK-8210496
Sorry, that is the JBS issue, the webrev is here:
 ?? http://cr.openjdk.java.net/~alanb/8210496/webrev/index.html

-Alan

From naoto.sato at oracle.com  Fri Sep 14 18:06:20 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 14 Sep 2018 11:06:20 -0700
Subject: <i18n dev> [12] RFR:8210490:TimeZone.getDisplayName given
 Locale.US doesn't always honor the Locale
In-Reply-To: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>
References: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>
Message-ID: <98da49f4-541a-3626-504c-41d30eb6848c@oracle.com>

Looks good.

Naoto

On 9/14/18 5:54 AM, Rachna Goel wrote:
> Hi,
> 
> Kindly review fix to JDK-8210490.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210490
> 
> Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/
> 
> This is a regression caused by JDK-8202537, where for timezones such as 
> Etc/GMT-5, display names got formatted according to default locale.
> 
> Fix is to specify locale, which was specified in 
> timezone.getDisplayName() method.
> 

From sean.mullan at oracle.com  Fri Sep 14 18:41:58 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Sep 2018 14:41:58 -0400
Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning"
 class can be dropped
In-Reply-To: <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
Message-ID: <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>

On 9/13/18 7:52 PM, Stuart Marks wrote:
> I'd guess that security-dev would have reviewers for the change to 
> default.policy. Cc'd.

The default.policy file change looks like this is not specifically 
related to this change because the jdk.desktop module no longer exists. 
I guess it is ok to include it with this change but I think someone else 
(maybe Phil Race) should double-check that is ok.

--Sean
> 
> s'marks
> 
> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>
>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>
>> During development of jdk9 it was considered that this API is not 
>> supported and may be removed in the future: JDK-8051640.
>> In jdk11 this class was marked as "forRemoval = true" (see 
>> JDK-8205588) and can be dropped in 12.
>>
>> In the fix these things were removed:
>> ??- com/sun/awt/SecurityWarning.java
>> ??- The test for SecurityWarning class
>> ??- Test groups, because SecurityWarning is the latest class in 
>> "com/sun/awt" package
>> ??- The reference to "com/sun/awt" in the "default.policy"
>>
>> (cc) core-libs-dev:
>> I am not sure who is responsible to review the change in 
>> "default.policy".
>>
>>

From federico.peralta at gmail.com  Fri Sep 14 19:11:11 2018
From: federico.peralta at gmail.com (Federico Peralta Schaffner)
Date: Fri, 14 Sep 2018 16:11:11 -0300
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
Message-ID: <CA+zu5po6PcQM=FfGca3nGGKOjCFFnvPrr3pdB4DzMp-T7ptcvw@mail.gmail.com>

Hi,

I've already sent an email to this list regarding this issue, but I'm not
sure if it finally made its way. So here I'm sending something again w.r.t
the name...

duplexing might be OK, but

collectingBothAndThen

is hard to beat.

Arguments:

- Existing collectingAndThen method is the simpler version of this guy, why
introducing other verbs?

- While being short (for all the things this operation does), it is yet an
extremely descriptive name; this method does exactly what its name says,
i.e. it really collects the stream using two collectors and then applies a
function to transform both collected results into the final result

- It reads naturally when used along with other existing methods of the
Collectors API, especially when used as a downstream collector, i.e.

filtering(
    n -> n > 0,
    collectingBothAndThen(
        summingDouble(e -> e.getDouble()),
        counting(),
        (sum, count) -> sum / count));


Just my 2 cents.

Thanks,
fps.-

El 14 set. 2018 2:44 p.m., "Tomasz Linkowski" <t.linkowski at gmail.com>
escribi?:

 Hi,

I'd like to remind three little things to which there was no response
(AFAIK):

1) Brian Goetz' suggestion of changing "? extends R" into "R":
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054947.html

2) Stuart Marks' suggestion about renaming "c1" and "c2" to "downstream1"
and "downstream2":
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html

3) my suggestion about renaming "merger" to "biFinisher" because "merger"
means BinaryOperator everywhere else:
    -
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055235.html


As to the name, I still think a name related to a well-understood concept
(like the composite pattern [1]) would be better. Note that "composite" is
also a verb [2], but "Collectors.compositing" looks a bit strange.
"Collectors.composing" seems much better to me, but - as far as I
understand - there was some concern that the users could misunderstand it
as element-wise composition, is that right?

Regards,
Tomasz Linkowski

[1] https://en.wikipedia.org/wiki/Composite_pattern
[2] https://en.wiktionary.org/wiki/composite#Verb



On Fri, Sep 14, 2018 at 11:23 AM, Peter Levart <peter.levart at gmail.com>

wrote:

> Hi Tagir,
>
> I like duplexing more than teeingAndThen. If consensus can be established
> about the name, I think you will then want to update the CSR draft to
> reflect new name. Then we'll kindly ask Stuart if he has any more advice
> before submitting the CSR...
>
> Regards, Peter
>
>
> On 09/14/2018 10:41 AM, Tagir Valeev wrote:
>
>> Hello, Stuart and Peter!
>>
>> Thank you for valuable comments. I updated the webrev:
>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
>>
>> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
>> "-ing" suffix shall present and I agree. Hopefully it's final name.
>> 2. I updated the spec as Stuart suggested.
>>
>> No changes in implementation since r3 revision. Please check.
>>
>> With best regards,
>> Tagir Valeev.
>>
>>
>> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com>
>> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>>
>


-- 
Pozdrawiam,
Tomasz Linkowski

From peter.levart at gmail.com  Fri Sep 14 19:16:18 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 14 Sep 2018 21:16:18 +0200
Subject: 8210496: Improve filtering for classes with security sensitive
 fields
In-Reply-To: <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
References: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
 <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
Message-ID: <ba5b578f-6908-25dc-b2ba-db2165495971@gmail.com>

Hi Alan,

Just a few comments about implementation.

In Reflection:

 ?292???????????? boolean shouldSkip = false;
 ?293???????????? for (String filteredName : filteredNames) {
 ?294???????????????? if (member.getName() == filteredName) {
 ?295???????????????????? shouldSkip = true;
 ?296???????????????????? break;
 ?297???????????????? }
 ?298???????????? }

...now that filteredNames is a Set<String>, you could simplify this loop to:

 ??? ??? shouldSkip = filteredNames.contains(member.getName());

The filter method then becomes:

 ??? private static Member[] filter(Member[] members, Set<String> 
filteredNames) {
 ??????? if ((filteredNames == null) || (members.length == 0)) {
 ??????????? return members;
 ??????? }
 ??????? if (filteredNames.contains(WILDCARD)) {
 ??????????? return (Member[]) Array.newInstance(members[0].getClass(), 0);
 ??????? }
 ??????? int numNewMembers = 0;
 ??????? for (Member member : members) {
 ??????????? if (!filteredNames.contains(member.getName())) {
 ??????????????? ++numNewMembers;
 ??????????? }
 ??????? }
 ??????? Member[] newMembers =
 ??????????? (Member[])Array.newInstance(members[0].getClass(), 
numNewMembers);
 ??????? int destIdx = 0;
 ??????? for (Member member : members) {
 ??????????? if (!filteredNames.contains(member.getName())) {
 ??????????????? newMembers[destIdx++] = member;
 ??????????? }
 ??????? }
 ??????? return newMembers;
 ??? }


I don't know if it's better, but you could use just the immutable Map 
without HashMap. Instead of:

 ?262???????? map = new HashMap<>(map);
 ?263???????? map.put(containingClass, Set.copyOf(names));
 ?264???????? return map;

you could do this:

 ??????? @SuppressWarnings("unchecked")
 ??????? Map.Entry<Class<?>, Set<String>>[] entries = 
map.entrySet().toArray(new Map.Entry[map.size() + 1]);
 ??????? entries[entries.length - 1] = Map.entry(containingClass, 
Set.copyOf(names));
 ??????? return Map.ofEntries(entries);

This should work because the registerFilter method is called at most 
once per map/containingClass.

Regards, Peter

On 09/14/2018 07:57 PM, Alan Bateman wrote:
>
>
> On 14/09/2018 18:52, Alan Bateman wrote:
>> Core reflection has a filtering mechanism to hide a number of fields 
>> that are critical to security or the integrity of the runtime. It's a 
>> bit of a band aid but it helps to reduce hacking on fields such as 
>> java.lang.System.security and java.lang.Class.classLoder. I'd like to 
>> extend the filters to hide a few additional fields from 
>> integrity-sensitive (and non-serializable) classes in 
>> java.lang.reflect and java.lang.invoke. There are of course a number 
>> of nasty hacks around that might break due to this but these hacks 
>> would be broken anyway with simple rename or other innocent 
>> refactoring (we had some of this during JDK 11 when Mandy fixed 
>> JDK-8202113 for example).
>>
>> The webrev with the changes is here:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8210496
> Sorry, that is the JBS issue, the webrev is here:
> ?? http://cr.openjdk.java.net/~alanb/8210496/webrev/index.html
>
> -Alan


From t.linkowski at gmail.com  Fri Sep 14 19:52:11 2018
From: t.linkowski at gmail.com (Tomasz Linkowski)
Date: Fri, 14 Sep 2018 21:52:11 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CA+zu5po6PcQM=FfGca3nGGKOjCFFnvPrr3pdB4DzMp-T7ptcvw@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <CA+zu5po6PcQM=FfGca3nGGKOjCFFnvPrr3pdB4DzMp-T7ptcvw@mail.gmail.com>
Message-ID: <CAD4YxQXWLo1yVN3ma79m8eQh6KArA1ocds8mG_a6oLqjgTxmQQ@mail.gmail.com>

Hi all,


Stuart, thanks for your response and explanations, I really appreciate it!
Good point about function composition - didn't cross my mind, but it could
be confusing indeed.

As for "merger" - good point about "biFinisher", but I'm still unconvinced
about "merger", because usually, you won't *merge* the two results (like
summing ints or concatenating strings) - instead, you'll usually *compose* them
into another object (yeah, and a moment before I said "composition" could
be confusing). But how about the name "duplexer" in the meaning of "to make
into a duplex"?

As for "duplex" not being a verb - according to some dictionaries, "duplex"
IS a verb:
- https://en.wiktionary.org/wiki/duplex#Verb
- https://www.dictionary.com/browse/duplex
- https://www.merriam-webster.com/dictionary/duplex

That said, I certainly wouldn't object against the word "composite" finding
its way into the JavaDoc.


Federico, since I proposed "collectingBothAndThen", I obviously agree with
you. To be honest, though, the major drawback of this name would be its
length (both wordwise and letterwise). On the other hand, it seems that
"collectingBothAndThen" could be much easier to understand than
"duplexing", especially for non-natives.


Regards,
Tomasz Linkowski


On Fri, Sep 14, 2018 at 9:11 PM, Federico Peralta Schaffner <
federico.peralta at gmail.com> wrote:

> Hi,
>
> I've already sent an email to this list regarding this issue, but I'm not
> sure if it finally made its way. So here I'm sending something again w.r.t
> the name...
>
> duplexing might be OK, but
>
> collectingBothAndThen
>
> is hard to beat.
>
> Arguments:
>
> - Existing collectingAndThen method is the simpler version of this guy, why
> introducing other verbs?
>
> - While being short (for all the things this operation does), it is yet an
> extremely descriptive name; this method does exactly what its name says,
> i.e. it really collects the stream using two collectors and then applies a
> function to transform both collected results into the final result
>
> - It reads naturally when used along with other existing methods of the
> Collectors API, especially when used as a downstream collector, i.e.
>
> filtering(
>     n -> n > 0,
>     collectingBothAndThen(
>         summingDouble(e -> e.getDouble()),
>         counting(),
>         (sum, count) -> sum / count));
>
>
> Just my 2 cents.
>
> Thanks,
> fps.-
>
> El 14 set. 2018 2:44 p.m., "Tomasz Linkowski" <t.linkowski at gmail.com>
> escribi?:
>
>  Hi,
>
> I'd like to remind three little things to which there was no response
> (AFAIK):
>
> 1) Brian Goetz' suggestion of changing "? extends R" into "R":
>     -
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> August/054947.html
>
> 2) Stuart Marks' suggestion about renaming "c1" and "c2" to "downstream1"
> and "downstream2":
>     -
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> August/054949.html
>
> 3) my suggestion about renaming "merger" to "biFinisher" because "merger"
> means BinaryOperator everywhere else:
>     -
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-
> September/055235.html
>
>
> As to the name, I still think a name related to a well-understood concept
> (like the composite pattern [1]) would be better. Note that "composite" is
> also a verb [2], but "Collectors.compositing" looks a bit strange.
> "Collectors.composing" seems much better to me, but - as far as I
> understand - there was some concern that the users could misunderstand it
> as element-wise composition, is that right?
>
> Regards,
> Tomasz Linkowski
>
> [1] https://en.wikipedia.org/wiki/Composite_pattern
> [2] https://en.wiktionary.org/wiki/composite#Verb
>
>
>
> On Fri, Sep 14, 2018 at 11:23 AM, Peter Levart <peter.levart at gmail.com>
>
> wrote:
>
> > Hi Tagir,
> >
> > I like duplexing more than teeingAndThen. If consensus can be established
> > about the name, I think you will then want to update the CSR draft to
> > reflect new name. Then we'll kindly ask Stuart if he has any more advice
> > before submitting the CSR...
> >
> > Regards, Peter
> >
> >
> > On 09/14/2018 10:41 AM, Tagir Valeev wrote:
> >
> >> Hello, Stuart and Peter!
> >>
> >> Thank you for valuable comments. I updated the webrev:
> >> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
> >>
> >> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
> >> "-ing" suffix shall present and I agree. Hopefully it's final name.
> >> 2. I updated the spec as Stuart suggested.
> >>
> >> No changes in implementation since r3 revision. Please check.
> >>
> >> With best regards,
> >> Tagir Valeev.
> >>
> >>
> >> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com>
> >> wrote:
> >>
> >>> 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
> >>>>>
> >>>>>
> >>>>>
> >
>
>
> --
> Pozdrawiam,
> Tomasz Linkowski
>



-- 
Pozdrawiam,
Tomasz Linkowski

From igor.ignatyev at oracle.com  Fri Sep 14 21:01:53 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 14 Sep 2018 14:01:53 -0700
Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils
In-Reply-To: <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com>
References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com>
 <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com>
Message-ID: <A0DA3EB3-889D-479E-A392-7C416AA3939A@oracle.com>

Alan, JC, thank you both for review
-- Igor

> On Sep 13, 2018, at 11:53 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 14/09/2018 01:07, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
>>> 478 lines changed: 3 ins; 319 del; 156 mod;
>> Hi all,
>> 
>> could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class?
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html
>> testing: tier[1-3] + :jdk_svc,:jdk_security_infra
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210732
>> 
> Looks good and only a few remaining classes in testlibrary to move.
> 
> -Alan


From philip.race at oracle.com  Fri Sep 14 21:48:19 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 14 Sep 2018 14:48:19 -0700
Subject: RFR: 8210766: Remove obsolete qualified export sun.net.www to
 java.desktop
Message-ID: <4b00f762-15f5-3420-1ff4-4b51f84372fa@oracle.com>

bug : https://bugs.openjdk.java.net/browse/JDK-8210766

The sun.applet implementation was removed a few days ago,
see http://hg.openjdk.java.net/jdk/client/rev/26a17d160081
This removed AppletClassLoader which consumed a class in sun.net.www
and thus needed a qualified export to java.desktop from java.base.
Now we don't need that qualified export any more .. so trivial diff below :

diff --git a/src/java.base/share/classes/module-info.java 
b/src/java.base/share/classes/module-info.java
--- a/src/java.base/share/classes/module-info.java
+++ b/src/java.base/share/classes/module-info.java
@@ -234,7 +234,6 @@
          jdk.jconsole,
          java.net.http;
      exports sun.net.www to
-        java.desktop,
          java.net.http,
          jdk.jartool;
      exports sun.net.www.protocol.http to

-phil.


From mandy.chung at oracle.com  Fri Sep 14 22:00:44 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 14 Sep 2018 15:00:44 -0700
Subject: RFR: 8210766: Remove obsolete qualified export sun.net.www to
 java.desktop
In-Reply-To: <4b00f762-15f5-3420-1ff4-4b51f84372fa@oracle.com>
References: <4b00f762-15f5-3420-1ff4-4b51f84372fa@oracle.com>
Message-ID: <2791d843-e76a-c034-36eb-84589eaecc8e@oracle.com>

+1

Mandy

On 9/14/18 2:48 PM, Phil Race wrote:
> bug : https://bugs.openjdk.java.net/browse/JDK-8210766
>
> The sun.applet implementation was removed a few days ago,
> see http://hg.openjdk.java.net/jdk/client/rev/26a17d160081
> This removed AppletClassLoader which consumed a class in sun.net.www
> and thus needed a qualified export to java.desktop from java.base.
> Now we don't need that qualified export any more .. so trivial diff 
> below :
>
> diff --git a/src/java.base/share/classes/module-info.java 
> b/src/java.base/share/classes/module-info.java
> --- a/src/java.base/share/classes/module-info.java
> +++ b/src/java.base/share/classes/module-info.java
> @@ -234,7 +234,6 @@
> ???????? jdk.jconsole,
> ???????? java.net.http;
> ???? exports sun.net.www to
> -??????? java.desktop,
> ???????? java.net.http,
> ???????? jdk.jartool;
> ???? exports sun.net.www.protocol.http to
>
> -phil.
>


From seth.lytle at gmail.com  Fri Sep 14 22:00:00 2018
From: seth.lytle at gmail.com (seth lytle)
Date: Fri, 14 Sep 2018 18:00:00 -0400
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <5B9BF4A4.5040605@oracle.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <CAJtn+Adnk0sg31g7Cuw8aTV9zsXKZAFZQNa8mODvazOTbhUgdw@mail.gmail.com>
 <5B9BF4A4.5040605@oracle.com>
Message-ID: <CAJtn+AcwNidgr1rA+S0=5=ECvhBpqFK2rDqEJZwwc1kqFky1cA@mail.gmail.com>

ah - compiler semantics vs launcher semantics, and the source code launcher
lives in both worlds

javac refuses to compile two sources for the same class
javac will compile a source file for a class that exists on the classpath
(and even overwrite a class on the classpath)
java accepts two class files for the same class on the classpath (favors
the first)
java -jar accepts a jar containing classes that also exist on the classpath
(favors the jar)
java refuses to launch a source file for a class that exists on the
classpath

the source code launcher "feels" like an outlier to me, but it could
certainly go either way

and i guess the source code launcher is an outlier anyway, as it decouples
the first toplevel class name from the file name












On Fri, Sep 14, 2018 at 1:49 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Seth,
>
> The reason for reporting an error is to prevent the "wrong" class being
> used!
>
> -- Jon
>
>
> On 09/14/2018 10:14 AM, seth lytle wrote:
>
>> this behavior of throwing an error if the class is found twice on the
>> classpath strikes me as unusual - afaik, in all other cases, java is fine
>> with finding multiple implementations on the classpath and uses the first
>> found (similar to the unix path, which also allows overriding by providing
>> an explicit path) and this is really one of the powerful features of java
>> -
>> allowing you to swap out one class for another seamlessly. and for rapid
>> prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs
>> much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and
>> doubly
>> so for mvnDebug
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>
>> Hi Jaikiran,
>>>
>>> Forwarding to compiler-dev as the core of source file launcher feature is
>>> produced there...
>>>
>>> The check for main class is performed after compilation (which actually
>>> produces the main class name).
>>>
>>> I think it would be possible to check for all classes compiled from the
>>> source file after compilation without to much complication. The
>>> compilation
>>> produces classes and stores them into a Map<String, byte[]>. The keySet()
>>> of that map is a Set of compiled class names. Each of them could be
>>> tested
>>> via .getResource() invoked upon the application class loader. The error
>>> could even point to the URL of the conflicting class file that way...
>>>
>>> Regards, Peter
>>>
>>>
>>> On 09/14/2018 07:36 AM, Jaikiran Pai wrote:
>>>
>>> Please consider this trivial code C.java:
>>>
>>> public class C {
>>>      public static void main(String[] args) throws Exception {
>>>          System.out.println("main() execution started");
>>>      }
>>> }
>>>
>>>
>>>
>>> ls
>>>
>>> C.java
>>>
>>> Similar to a previous discussion[1] while doing random testing, I ended
>>> up compiling C.java explicitly using javac:
>>>
>>>
>>> javac C.java
>>> ls
>>>
>>> C.java C.class
>>>
>>> and then at a later date tried to use the source file launcher feature
>>> of Java 11 (without realizing C.class was already present in the dir):
>>>
>>>
>>> java C.java
>>>
>>> This threw the error:
>>>
>>> error: class found on application class path: C
>>>
>>> Although the error isn't that clear for the reason I note in [2], having
>>> run into this before, I was aware what this meant and deleted the
>>> C.class and moved on. The important part here is that the source
>>> launcher noticed this condition and aborted even before it auto
>>> compiled(?) and launched and executed the main() of the program.
>>>
>>> Now consider a slight modification to that source file:
>>>
>>> public class C {
>>>      public static void main(String[] args) throws Exception {
>>>          System.out.println("main() execution started");
>>>          final B b = new B();
>>>          System.out.println("Done");
>>>      }
>>>
>>>      private static class B {
>>>
>>>      }
>>> }
>>>
>>> Again at some point I compiled this explicitly using javac, so my
>>> directory is (among other things):
>>>
>>>
>>> ls
>>>
>>> C$B.class    C.class        C.java
>>>
>>> Then ran the source file launcher feature:
>>>
>>>
>>> java C.java
>>>
>>> error: class found on application class path: C
>>>
>>> As expected, ran into the same previous error. As before, in order to
>>> move on, deleted C.class:
>>>
>>>
>>> rm C.class
>>>
>>> but forgot to delete the nested static class that belonged to it. So the
>>> directory now contained:
>>>
>>>
>>> ls
>>>
>>> C$B.class    C.java
>>>
>>> Now used the source launcher feature again:
>>>
>>>
>>> java C.java
>>>
>>> This time it failed with:
>>>
>>> main() execution started
>>> Exception in thread "main" java.lang.IllegalAccessError: failed to
>>> access class C$B from class C (C$B is in unnamed module of loader 'app';
>>> C is in unnamed module of loader
>>> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
>>>      at C.main(C.java:4)
>>>
>>> The error message isn't clear to pinpoint the issue, but at least the
>>> reference to MemoryClassLoader was a hint that was enough for me to
>>> understand where to look. It did take me a few minutes to realize that
>>> C$B.class was lying around which I needed to remove too.
>>>
>>> However, IMO, the important part here is that unlike in the first case
>>> where the program itself wasn't launched and instead was aborted early,
>>> in this case the program did get executed (notice the System.out.println
>>> "main() execution started" message that got printed) and failed at
>>> runtime.
>>>
>>> Would it be possible to make these two behaviours consistent and detect
>>> such cases and abort early here too? Or would that add too much
>>> complexity to this feature?
>>>
>>> Finally, any thoughts on the error messages for this feature to make it
>>> a bit easier in terms of debugging (classloading) issues like these?
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
>>> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html
>>>
>>> -Jaikiran
>>>
>>>
>>>
>>>
>>>
>

From jonathan.gibbons at oracle.com  Fri Sep 14 22:09:03 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 14 Sep 2018 15:09:03 -0700
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <CAJtn+AcwNidgr1rA+S0=5=ECvhBpqFK2rDqEJZwwc1kqFky1cA@mail.gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <CAJtn+Adnk0sg31g7Cuw8aTV9zsXKZAFZQNa8mODvazOTbhUgdw@mail.gmail.com>
 <5B9BF4A4.5040605@oracle.com>
 <CAJtn+AcwNidgr1rA+S0=5=ECvhBpqFK2rDqEJZwwc1kqFky1cA@mail.gmail.com>
Message-ID: <4070f498-b1ec-1eb8-6b4b-501c406f8b3e@oracle.com>

Seth, this is not so much "compiler semantics" vs "launcher semantics" 
... it's just "ClassLoader semantics", combined with the fact that an 
empty class path defaults to the current directory.

In the source launcher, the compiler is not worried about the classes in 
the current directory.

But the classes are executed in a class loader, in which the normal 
semantics[1] are to check the parent class loader first, before checking 
for a local definition. Using those normal semantics, any classes on the 
application class path (defaulting to the current directory) are found 
before those defined to the class loader. That's the problem that is 
being encountered here.

-- Jon

[1]https://docs.oracle.com/javase/10/docs/api/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean)

On 9/14/18 3:00 PM, seth lytle wrote:
> ah - compiler semantics vs launcher semantics, and the source code 
> launcher lives in both worlds
>
> javac refuses to compile two sources for the same class
> javac will compile a source file for a class that exists on the 
> classpath (and even overwrite a class on the classpath)
> java accepts two class files for the same class on the classpath 
> (favors the first)
> java -jar accepts a jar containing classes that also exist on the 
> classpath (favors the jar)
> java refuses to launch a source file for a class that exists on the 
> classpath
>
> the source code launcher "feels" like an outlier to me, but it could 
> certainly go either way
>
> and i guess the source code launcher is an outlier anyway, as it 
> decouples the first toplevel class name from the file name
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Sep 14, 2018 at 1:49 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Seth,
>
>     The reason for reporting an error is to prevent the "wrong" class
>     being used!
>
>     -- Jon
>
>
>     On 09/14/2018 10:14 AM, seth lytle wrote:
>
>         this behavior of throwing an error if the class is found twice
>         on the
>         classpath strikes me as unusual - afaik, in all other cases,
>         java is fine
>         with finding multiple implementations on the classpath and
>         uses the first
>         found (similar to the unix path, which also allows overriding
>         by providing
>         an explicit path) and this is really one of the powerful
>         features of java -
>         allowing you to swap out one class for another seamlessly. and
>         for rapid
>         prototyping, "java -cp target/classes:$cp
>         src/myPackage/Stuff.java" runs
>         much faster than "mvn package
>         -Dexec.mainClass=myPackage.Stuff", and doubly
>         so for mvnDebug
>
>
>
>
>
>
>
>
>
>
>         On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart
>         <peter.levart at gmail.com <mailto:peter.levart at gmail.com>>
>         wrote:
>
>             Hi Jaikiran,
>
>             Forwarding to compiler-dev as the core of source file
>             launcher feature is
>             produced there...
>
>             The check for main class is performed after compilation
>             (which actually
>             produces the main class name).
>
>             I think it would be possible to check for all classes
>             compiled from the
>             source file after compilation without to much
>             complication. The compilation
>             produces classes and stores them into a Map<String,
>             byte[]>. The keySet()
>             of that map is a Set of compiled class names. Each of them
>             could be tested
>             via .getResource() invoked upon the application class
>             loader. The error
>             could even point to the URL of the conflicting class file
>             that way...
>
>             Regards, Peter
>
>
>             On 09/14/2018 07:36 AM, Jaikiran Pai wrote:
>
>             Please consider this trivial code C.java:
>
>             public class C {
>             ? ? ?public static void main(String[] args) throws Exception {
>             ? ? ? ? ?System.out.println("main() execution started");
>             ? ? ?}
>             }
>
>
>
>             ls
>
>             C.java
>
>             Similar to a previous discussion[1] while doing random
>             testing, I ended
>             up compiling C.java explicitly using javac:
>
>
>             javac C.java
>             ls
>
>             C.java C.class
>
>             and then at a later date tried to use the source file
>             launcher feature
>             of Java 11 (without realizing C.class was already present
>             in the dir):
>
>
>             java C.java
>
>             This threw the error:
>
>             error: class found on application class path: C
>
>             Although the error isn't that clear for the reason I note
>             in [2], having
>             run into this before, I was aware what this meant and
>             deleted the
>             C.class and moved on. The important part here is that the
>             source
>             launcher noticed this condition and aborted even before it
>             auto
>             compiled(?) and launched and executed the main() of the
>             program.
>
>             Now consider a slight modification to that source file:
>
>             public class C {
>             ? ? ?public static void main(String[] args) throws Exception {
>             ? ? ? ? ?System.out.println("main() execution started");
>             ? ? ? ? ?final B b = new B();
>             ? ? ? ? ?System.out.println("Done");
>             ? ? ?}
>
>             ? ? ?private static class B {
>
>             ? ? ?}
>             }
>
>             Again at some point I compiled this explicitly using
>             javac, so my
>             directory is (among other things):
>
>
>             ls
>
>             C$B.class? ? C.class? ? ? ? C.java
>
>             Then ran the source file launcher feature:
>
>
>             java C.java
>
>             error: class found on application class path: C
>
>             As expected, ran into the same previous error. As before,
>             in order to
>             move on, deleted C.class:
>
>
>             rm C.class
>
>             but forgot to delete the nested static class that belonged
>             to it. So the
>             directory now contained:
>
>
>             ls
>
>             C$B.class? ? C.java
>
>             Now used the source launcher feature again:
>
>
>             java C.java
>
>             This time it failed with:
>
>             main() execution started
>             Exception in thread "main" java.lang.IllegalAccessError:
>             failed to
>             access class C$B from class C (C$B is in unnamed module of
>             loader 'app';
>             C is in unnamed module of loader
>             com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab)
>             ? ? ?at C.main(C.java:4)
>
>             The error message isn't clear to pinpoint the issue, but
>             at least the
>             reference to MemoryClassLoader was a hint that was enough
>             for me to
>             understand where to look. It did take me a few minutes to
>             realize that
>             C$B.class was lying around which I needed to remove too.
>
>             However, IMO, the important part here is that unlike in
>             the first case
>             where the program itself wasn't launched and instead was
>             aborted early,
>             in this case the program did get executed (notice the
>             System.out.println
>             "main() execution started" message that got printed) and
>             failed at runtime.
>
>             Would it be possible to make these two behaviours
>             consistent and detect
>             such cases and abort early here too? Or would that add too
>             much
>             complexity to this feature?
>
>             Finally, any thoughts on the error messages for this
>             feature to make it
>             a bit easier in terms of debugging (classloading) issues
>             like these?
>
>             [1]
>             http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html
>             <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html>
>             [2]
>             http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html
>             <http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html>
>
>             -Jaikiran
>
>
>
>
>
>


From mark.reinhold at oracle.com  Fri Sep 14 22:31:33 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 14 Sep 2018 15:31:33 -0700
Subject: 8207690: Parsing API for classpath and similar path strings
In-Reply-To: <462c5054-075a-e43c-a838-5460ddbbe314@Oracle.com>
References: <46734250-094f-b4b3-d0c0-931d32e96833@Oracle.com>
 <e874fc5c-9bdb-4ec7-9db1-d356c3a966a0@oracle.com>
 <917fa123-1dee-cf51-deaf-df75298e2474@oracle.com>
 <e35da7a3-48e6-89a9-d809-ce4d04cd6f94@oracle.com>
 <2f9d4e1a-16fe-44d5-c934-6fdbc23f00f3@Oracle.com>
 <bc7925ec-70fe-ff58-f5aa-8bfd52e6c34a@oracle.com>
 <00fcc718-c39b-1aea-c430-1b550bccb4e3@Oracle.com>
 <5B96D85B.9000807@oracle.com>
 <77168a25-165a-333f-8870-05eb086c2988@Oracle.com>
 <1c74f4f6-d786-9d74-2c43-dafd21ebd48d@oracle.com>
 <CACzrW9AG5_U12P0J64jXJg4ig56CzV42xcOZq_TEjKBwOM2sCg@mail.gmail.com>
 <11da04fd-b711-32b6-59a0-0660efb731a2@oracle.com>
 <462c5054-075a-e43c-a838-5460ddbbe314@Oracle.com>
Message-ID: <20180914153133.892454309@eggemoggin.niobe.net>

2018/9/13 10:21:26 -0700, roger.riggs at oracle.com:
> Consider:
> 
> public class SearchPath {
>   public static SearchPath of(String searchPath) {...}
> public static SearchPath of(List<String> elements) {...}
> public Stream<String> stream() {...}
> public List<String> asList() {...}
>   public String toString() {...}
>   private SearchPath() {};
> }
> 
> A SearchPath can be constructed from various forms of search path 
> elements and can create other forms as needed.
> As a class it would be extensible and can start small and grow as needed.
> 
> Examples:
>    List<String> list = SearchPath.of("a:b:c").asList();
> 
>  Path p = SearchPath.of("x:y:z").stream()
>     .filter(Predicate.not(String::isEmpty))
>     .map(Path::of)
>     .filter(Files::isDirectory)
>   .filter(q -> Files.exists(q.resolve("x.jar)))
>     .findFirst()
>     .orElseThrow();
> 
> If that seems like a reasonable base, I (or some other volunteer) can 
> flesh it out with the suggestions.

Yes -- this is along the lines of what I was trying to suggest.
Stick to the goal of representing a search path, and leave actual
I/O operations, if any, to the caller.

I think that puts this class squarly in the realm of java.util
rather than java.nio.file.

- Mark

From igor.ignatyev at oracle.com  Fri Sep 14 23:09:59 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 14 Sep 2018 16:09:59 -0700
Subject: RFR(XS) : 8210779 : 8182404 and 8210732 haven't updated copyright
 years
Message-ID: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com>

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

Hi all,

could you please review this small and trivial follow-up fix for 8182404 and 8210732? I have forgot to update copyright years as a part of these two changesets, this patch fixes that.

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

Thanks,
-- Igor

From brent.christian at oracle.com  Sat Sep 15 00:16:26 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 14 Sep 2018 17:16:26 -0700
Subject: RFR(XS) : 8210779 : 8182404 and 8210732 haven't updated copyright
 years
In-Reply-To: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com>
References: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com>
Message-ID: <3446af1d-b4e5-1d47-0614-910d040e4cb1@oracle.com>

Looks like you got them all - reviewed.

-Brent
On 09/14/2018 04:09 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html
>> 36 lines changed: 0 ins; 0 del; 36 mod;
>
> Hi all,
>
> could you please review this small and trivial follow-up fix for 8182404 and 8210732? I have forgot to update copyright years as a part of these two changesets, this patch fixes that.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210779
>
> Thanks,
> -- Igor
>


From mandy.chung at oracle.com  Sat Sep 15 02:03:04 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 14 Sep 2018 19:03:04 -0700
Subject: 8210496: Improve filtering for classes with security sensitive
 fields
In-Reply-To: <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
References: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
 <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
Message-ID: <9d69c363-47cd-ff6d-9e2e-22ce670dc8c5@oracle.com>



On 9/14/18 10:57 AM, Alan Bateman wrote:
>
> ?? http://cr.openjdk.java.net/~alanb/8210496/webrev/index.html
>

This looks good.

I like Peter's suggestion to? simplify line 292-301 and 307-316 in 
Reflection.java
and replace the loop with filteredNames::contains check.

Mandy

From amaembo at gmail.com  Sat Sep 15 02:34:37 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 15 Sep 2018 09:34:37 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <1ba2d793-66ba-e7e9-ba6d-c160344e557a@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
Message-ID: <CAE+3fjYLVzBAC8fgxVDBYn3OhE_kitGpK5GYWVX5F73B_KgHNQ@mail.gmail.com>

Hello!

Tomasz, Peter, Stuart, Remi, thank you for review and comments. I
updated the webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r5/
1. ? extends R -> R
2. parameter names c1, c2 -> downstream1, downstream2;
Objects.requireNonNull messages updated correspondingly

merger is left as is. I think it's fine.

>> Returns a {@code Collector} that is a composite of two downstream collectors.
>
> even though it uses "composite" which is not the name of this collector. But I think it's a more descriptive term and it reads more smoothly.

I also think that using a different word in description is fine. It
could be helpful for non-native speakers (some may better understand
'duplex', others are more familiar with 'composite').

CSR is also updated:
https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8209685

With best regards,
Tagir Valeev.

On Sat, Sep 15, 2018 at 12:09 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> Hi Tagir, thanks for the update.
>
> Also thanks Tomasz for keeping everybody honest on the open issues.
>
> First, naming. I think "duplex" as the root word wins! Using "duplexing" to conform to many of other collectors is fine; so, "duplexing" is good.
>
> Unfortunately "duplex" is not really a verb. For some reason "duplexing" sounds OK. This probably follows in the long tradition of the tech industry's "verbing" of nouns and adjectives. However, I can't quite bring myself to recommend using this in the javadoc summary sentence, e.g.,
>
> Returns a {@code Collector} that duplexes stream elements to two downstream collectors.
>
> Ugh. I think the current summary sentence is fine
>
> Returns a {@code Collector} that is a composite of two downstream collectors.
>
> even though it uses "composite" which is not the name of this collector. But I think it's a more descriptive term and it reads more smoothly.
>
> Turning to the issues mentioned by Tomasz:
>
> 1) Brian Goetz' suggestion of changing "? extends R" into "R":
>     - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054947.html
>
> Yes, I think this should be done.
>
> 2) Stuart Marks' suggestion about renaming "c1" and "c2" to "downstream1" and "downstream2":
>     - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html
>
> Yes. It's a small thing, but the parameter names do appear in the javadoc. The text refers to "downstream" collectors, and naming the parameters "downstream" strengthens the association to the text. Otherwise, the reader has to think "what are c1 and c2? Oh, they're the downstream collectors."
>
> 3) my suggestion about renaming "merger" to "biFinisher" because "merger" means BinaryOperator everywhere else:
>     - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055235.html
>
> I'm ok with "merger". I don't feel that "merge" has a strong implication that the result must be the same type as the two inputs. I'm ok with the notion of "merge" taking two inputs (which might be of different types) and producing a single output (which might be a different type from either input). The difficulty with "biFinisher" is that it doesn't seem to imply "take two things and produce one". A finisher takes one input and produces one output, so would a "biFinisher" take two inputs and produce two outputs?
>
> As to the name, I still think a name related to a well-understood concept (like the composite pattern [1]) would be better. Note that "composite" is also a verb [2], but "Collectors.compositing" looks a bit strange. "Collectors.composing" seems much better to me, but - as far as I understand - there was some concern that the users could misunderstand it as element-wise composition, is that right?
>
> The difficulty I have with "compose" and "composition" is that with function composition, one function is applied, and the second function is applied to the result of the first. Of course that isn't what happens here. The notion of "duplexing" is that things are happening side-by-side, which applies well here, I think.
>
> **
>
> Tagir, overall, looks good! Let me know when you've finished updating the CSR.
>
> Thanks,
>
> s'marks
>
>
> Regards,
> Tomasz Linkowski
>
> [1] https://en.wikipedia.org/wiki/Composite_pattern
> [2] https://en.wiktionary.org/wiki/composite#Verb
>
>
>
> On Fri, Sep 14, 2018 at 11:23 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> Hi Tagir,
>>
>> I like duplexing more than teeingAndThen. If consensus can be established about the name, I think you will then want to update the CSR draft to reflect new name. Then we'll kindly ask Stuart if he has any more advice before submitting the CSR...
>>
>> Regards, Peter
>>
>>
>> On 09/14/2018 10:41 AM, Tagir Valeev wrote:
>>>
>>> Hello, Stuart and Peter!
>>>
>>> Thank you for valuable comments. I updated the webrev:
>>> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r4/
>>>
>>> 1. I renamed "teeingAndThen" to "duplexing". Brian insisted that
>>> "-ing" suffix shall present and I agree. Hopefully it's final name.
>>> 2. I updated the spec as Stuart suggested.
>>>
>>> No changes in implementation since r3 revision. Please check.
>>>
>>> With best regards,
>>> Tagir Valeev.
>>>
>>>
>>> On Tue, Aug 21, 2018 at 12:43 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>>>>
>>>> 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
>>>>>>
>>>>>>
>>
>
>
>
> --
> Pozdrawiam,
> Tomasz Linkowski
>
>

From jai.forums2013 at gmail.com  Sat Sep 15 02:50:57 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 15 Sep 2018 08:20:57 +0530
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
Message-ID: <ae1e2c94-12d4-ece7-0775-4c72318e95ea@gmail.com>

Hello Peter,


On 14/09/18 1:03 PM, Peter Levart wrote:
>
> The check for main class is performed after compilation (which
> actually produces the main class name).
>
> I think it would be possible to check for all classes compiled from
> the source file after compilation without to much complication. The
> compilation produces classes and stores them into a Map<String,
> byte[]>. The keySet() of that map is a Set of compiled class names.
> Each of them could be tested via .getResource() invoked upon the
> application class loader. The error could even point to the URL of the
> conflicting class file that way...
>

Thank you for moving this to the correct mailing list. Thanks for those
details about how it's done and what can be done to improve this. Should
I report this as an enhancement request at bugs.java.com? I don't have
access to the OpenJDK JIRA for creating this request there.

-Jaikiran

From ivan.gerasimov at oracle.com  Sat Sep 15 05:44:47 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 14 Sep 2018 22:44:47 -0700
Subject: RFR 8210787 : Object.wait(long, int) throws inappropriate
 IllegalArgumentException
Message-ID: <8347fa30-6c13-cf97-dac4-a1e17d203f30@oracle.com>

Hello!

This is inspired by a recent fix for JDK- 8210004 (Thread.sleep(millis, 
nanos) timeout returns early).

Currently, Object.wait(Long.MAX_VALUE, 1) would throw 
"IllegalArgumentException: timeout value is negative", which is not 
accurate.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210787
WEBREV: http://cr.openjdk.java.net/~igerasim/8210787/00/webrev/

-- 
With kind regards,
Ivan Gerasimov


From jai.forums2013 at gmail.com  Sat Sep 15 08:49:44 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 15 Sep 2018 14:19:44 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
Message-ID: <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>

Hello Stuart,

Thank you very much for the detailed review. I have attached an updated
patch which incorporates the suggested changes. The complete javadoc
text is included inline here and a few comments are inline in the rest
of this mail:

??? /**
???? * Returns a fixed-size list backed by the specified array. Changes
made to
???? * the array will be visible in the returned list, and changes made
to the
???? * list will be visible in the array. The returned list is
???? * {@link Serializable} and implements {@link RandomAccess}.
???? *
???? * <p>The returned list can be changed only in certain ways. Operations
???? * that would change the size of the returned list leave the list
unchanged
???? * and throw {@link UnsupportedOperationException}.
???? *
???? * @apiNote
???? * This method acts as bridge between array-based and collection-based
???? * APIs, in combination with {@link Collection#toArray}.
???? *
???? * <p>This method provides a way to wrap an existing array:
???? * <pre>
???? *???? Integer[] numbers = ...
???? *???? ...
???? *???? List&lt;Integer&gt; values = Arrays.asList(numbers);
???? * </pre>
???? *
???? * <p>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 list returned by this method is <em>not</em>
???? * <a href="{@docRoot}/java.base/java/util/List.html#unmodifiable">
???? * unmodifiable</a>
???? *
???? * @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
???? * @throws NullPointerException if the passed array is {@code null}
???? */


On 11/09/18 7:54 AM, Stuart Marks wrote:
>
>
>> The passed array is held as a reference in the returned list.
>
> While this is true, this is really a statement about implementation.
> For the specification, we want to focus on assertions about the
> behavior. Please remove.

Done.
>
>> 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.
>
> This is an improvement on the original "(Changes to the returned list
> "write through" to the array)" which doesn't describe the behavior
> precisely enough nor does it discuss the "bi-directional" nature of
> visibility of the changes. The proposed text is a bit verbose,
> however; I'd suggest the following:
>
> ??? Changes made to the array will be visible in the returned list, and
> ??? changes made to the list will be visible in the array.

Done. I agree the my previous version in the patch was verbose and what
you suggest looks better.
>
>
>> The returned list is serializable and implements {@link RandomAccess}.
>
> (This was from the original text.) It's kind of odd that RandomAccess
> is a link but Serializable is not. I'd suggest making Serializable a
> link as follows:

Done.
>
>> ???? * <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.
>
> This text would be fine for something like a tutorial, but it's not
> precise enough in that it describes behavior by example ("operations
> like...") and it doesn't specify the behavior if a disallowed
> operation is performed. I'd suggest this instead:
>
> ??? Operations that would change the size of the returned list leave the
> ??? list unchanged and throw {@link UnsupportedOperationException}.

Done.
>
>
> Listing the exact methods that can change the size is unwise, as it
> can change over time and the list will become out of date. There are
> also a lot of obscure ways to change the size of a list besides
> methods on the list, e.g. via an iterator's remove(), a sublist's
> size-change method, removeIf(), etc. and it's not worth trying to
> chase them all down.

Agreed. In fact that was the reason why I originally used "operations
like...", but your suggested change above, to this text, I believe
covers all these relevant APIs.

>
>
>> This method acts as bridge between array-based and collection-based
>> APIs, in
>> combination with {@link Collection#toArray}.
>
> This (from the original text) should actually be part of the @apiNote.
> However, it was written before the @apiNote concept existed. So, start
> the @apiNote before this text.

Done.
>
>> 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.
> This UOE statement now redundant with the above.
>
This has now been removed in favour of the suggested change.

>
> I do think it's reasonable to have examples here. Interestingly, the
> original (pre-varargs) purpose of Arrays.asList() was to wrap an
> existing array in a list. With varargs, this method is probably now
> more often used to create a list from arguments. Both uses are valid,
> but the first is now less obvious and so I think deserves a new
> example. The latter remains valid even with List.of() and friends,
> since those methods make a copy of the array that might not be
> necessary in all cases.
>
> Here's what I'd suggest:
>
> ?- add a simple (~2 line) example showing wrapping of an existing array
> ?? in a list
Done. Added a new example to show this:

???? * <p>This method provides a way to wrap an existing array:
???? * <pre>
???? *???? Integer[] numbers = ...
???? *???? ...
???? *???? List&lt;Integer&gt; values = Arrays.asList(numbers);
???? * </pre>

While adding this, I realized that the current javadoc doesn't mention
anything about the behaviour of this method when a null array is passed
to it. The implementation currently throws a NullPointerException. So I
went ahead and updated the javadoc to include:

???? * @throws NullPointerException if the passed array is {@code null}


>
> ?- restore the "Three Stooges" example (beginning with "This method
> also provides...")

Done.
>
> ?- add a note emphasizing that the returned list is NOT unmodifiable.
> it's a common mistake to assume that it is. I'd also put in a
> reference to List.html#unmodifiable here in case people do want an
> unmodifiable list.

Done. I looked up the javadoc style guide[1] (is that still relevant,
especially for contributions to the JDK itself?) and javadoc of some
"recent" files within the JDK code, to see what's the current way to
emphasize certain parts of the comments. I couldn't find anything
conclusive, so I decided to use "<em>". Let me know if there's some
other preferred way.
>
>> ???? * @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
>> ???? * @see List#of()
>
> OK. We probably don't need the @see for List.of if there's a reference
> to the "unmodifiable lists" section above.

Done. "@see List#of()" is now removed in this updated version. Bernd,
let us know if you agree that this update to include reference to the
List.html#unmodifiable covers the use case for which we introduced the
List#of() reference.
>
>
> I can sponsor this change for you. Since we're changing testable
> assertions, this will also require a CSR request. I'll take care of
> that for you too.
Thank you :)

[1]
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide

-Jaikiran

-------------- next part --------------
# HG changeset patch
# User Jaikiran Pai <jaikiran.pai at gmail.com>
# Date 1535208403 -19800
#      Sat Aug 25 20:16:43 2018 +0530
# Node ID fbb71a7edc1aeeb6065e309a3efa67bc7ead6a3c
# Parent  6c394ed56b07d453226e064bc011528cd89b7d69
JDK-7033681 Improve the javadoc of Arrays#toList()

diff --git a/src/java.base/share/classes/java/util/Arrays.java b/src/java.base/share/classes/java/util/Arrays.java
--- a/src/java.base/share/classes/java/util/Arrays.java
+++ b/src/java.base/share/classes/java/util/Arrays.java
@@ -28,6 +28,7 @@
 import jdk.internal.HotSpotIntrinsicCandidate;
 import jdk.internal.util.ArraysSupport;
 
+import java.io.Serializable;
 import java.lang.reflect.Array;
 import java.util.concurrent.ForkJoinPool;
 import java.util.function.BinaryOperator;
@@ -4288,11 +4289,25 @@
     // 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}.
+     * Returns a fixed-size list backed by the specified array. Changes made to
+     * the array will be visible in the returned list, and changes made to the
+     * list will be visible in the array. The returned list is
+     * {@link Serializable} and implements {@link RandomAccess}.
+     *
+     * <p>The returned list can be changed only in certain ways. Operations
+     * that would change the size of the returned list leave the list unchanged
+     * and throw {@link UnsupportedOperationException}.
+     *
+     * @apiNote
+     * This method acts as bridge between array-based and collection-based
+     * APIs, in combination with {@link Collection#toArray}.
+     *
+     * <p>This method provides a way to wrap an existing array:
+     * <pre>
+     *     Integer[] numbers = ...
+     *     ...
+     *     List&lt;Integer&gt; values = Arrays.asList(numbers);
+     * </pre>
      *
      * <p>This method also provides a convenient way to create a fixed-size
      * list initialized to contain several elements:
@@ -4300,9 +4315,14 @@
      *     List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe", "Curly");
      * </pre>
      *
+     * <p>The list returned by this method is <em>not</em>
+     * <a href="{@docRoot}/java.base/java/util/List.html#unmodifiable">
+     * unmodifiable</a>
+     *
      * @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
+     * @throws NullPointerException if the passed array is {@code null}
      */
     @SafeVarargs
     @SuppressWarnings("varargs")

From martinrb at google.com  Sat Sep 15 14:33:57 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 15 Sep 2018 07:33:57 -0700
Subject: RFR 8210787 : Object.wait(long,
 int) throws inappropriate IllegalArgumentException
In-Reply-To: <8347fa30-6c13-cf97-dac4-a1e17d203f30@oracle.com>
References: <8347fa30-6c13-cf97-dac4-a1e17d203f30@oracle.com>
Message-ID: <CA+kOe089T7oZiJPFULmkoCfFroi9YppHd2k8vaWHSgvSQqoqcQ@mail.gmail.com>

Looks good!

On Fri, Sep 14, 2018 at 10:44 PM, Ivan Gerasimov
<ivan.gerasimov at oracle.com> wrote:
> Hello!
>
> This is inspired by a recent fix for JDK- 8210004 (Thread.sleep(millis,
> nanos) timeout returns early).
>
> Currently, Object.wait(Long.MAX_VALUE, 1) would throw
> "IllegalArgumentException: timeout value is negative", which is not
> accurate.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210787
> WEBREV: http://cr.openjdk.java.net/~igerasim/8210787/00/webrev/
>
> --
> With kind regards,
> Ivan Gerasimov
>

From Roger.Riggs at Oracle.com  Sat Sep 15 15:35:13 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 15 Sep 2018 11:35:13 -0400
Subject: RFR 8210787 : Object.wait(long, int) throws inappropriate
 IllegalArgumentException
In-Reply-To: <CA+kOe089T7oZiJPFULmkoCfFroi9YppHd2k8vaWHSgvSQqoqcQ@mail.gmail.com>
References: <8347fa30-6c13-cf97-dac4-a1e17d203f30@oracle.com>
 <CA+kOe089T7oZiJPFULmkoCfFroi9YppHd2k8vaWHSgvSQqoqcQ@mail.gmail.com>
Message-ID: <9096ef68-801a-6c8c-b735-c00099413536@Oracle.com>

+1

On 9/15/2018 10:33 AM, Martin Buchholz wrote:
> Looks good!
>
> On Fri, Sep 14, 2018 at 10:44 PM, Ivan Gerasimov
> <ivan.gerasimov at oracle.com> wrote:
>> Hello!
>>
>> This is inspired by a recent fix for JDK- 8210004 (Thread.sleep(millis,
>> nanos) timeout returns early).
>>
>> Currently, Object.wait(Long.MAX_VALUE, 1) would throw
>> "IllegalArgumentException: timeout value is negative", which is not
>> accurate.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210787
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8210787/00/webrev/
>>
>> --
>> With kind regards,
>> Ivan Gerasimov
>>


From brian.goetz at oracle.com  Sat Sep 15 15:36:45 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 15 Sep 2018 11:36:45 -0400
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <1ba2d793-66ba-e7e9-ba6d-c160344e557a@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
Message-ID: <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>

tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely 
to be a name we regret, for reasons outlined below.


The behavior of this Collector is:
 ?- duplicate the stream into two identical streams
 ?- collect the two streams with two collectors, yielding two results
 ?- merge the two results into a single result

Obviously, a name like `duplexingAndCollectingAndThenMerging`, which, 
entirely accurate and explanatory, is "a bit" unwieldy.? So the 
questions are:
 ?- how much can we drop and still be accurate
 ?- which parts are best to drop.

When we pick names, we are not just trying to pick the best name for 
now, but we should imagine all the possible operations one might ever 
want to do in the future (names in the JDK are forever) and make a 
reasonable attempt to imagine whether this could cause confusion or 
regret in the future.

To evaluate "duplexing" here (which seems the most important thing to 
keep), I'd ask: is there any other reasonable way to imagine a 
`duplexing` collect operation, now or in the future?

One could imagine wanting an operation that takes a stream and produces 
two streams whose contents are that of the original stream.? And 
"duplex" is a good name for that.? But, it is not a Collector; it would 
be a stream transform, like concat.? So that doesn't seem a conflict; a 
duplexing collector and a duplexing stream transform are sort of from 
"different namespaces."

Can one imagine a "duplexing" Collector that doesn't do any collection?? 
I cannot.? Something that returns a pair of streams would not be a 
Collector, but something else. So dropping AndCollecting seems justified.

What about "AndThenMerging"?? The purpose of collect is to reduce the 
stream into a summary description.? Can we imagine a duplexing operation 
that doesn't merge the two results, but instead just returns a tuple of 
the results?? Yes, I can totally imagine this, especially once we have 
value types and records, which makes returning ad-hoc tuples cheaper 
(syntactically, heap-wise, CPU-wise.)? So I think this is quite a 
reasonable possibility. But, I would have no problem with an overload 
that didn't take a merger and returned a tuple of the result, and was 
still called `duplexing`.

So I'm fine with dropping all the extra AndThisAndThat.

Finally, there's one other obvious direction we might extend this -- 
more than two collectors.? There's no reason why we can only do two; we 
could take a (likely homogeneous) varargs of Collectors, and return a 
List of results -- which itself could then be streamed into another 
collector.? This actually sounds pretty useful (though I'm not 
suggesting doing this right now.) And, I think it would be silly if this 
were not called the same thing as the two-collector version (just as it 
would be silly to have separate names for "concat two" and "concat n".)

And, this is where I think "duplexing" runs out of gas -- duplex implies 
"two".? Pedantic argue-for-the-sake-of-argument folks might observe that 
"tee" also has bilateral symmetry, but I don't think you could 
reasonably argue that a four-way "tee" is not less of an arity abuse 
than a four-way "duplex", and the plumbing industry would agree:

https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM

So, for these reasons, I still think "teeing" has a better balance of 
being both evocative what it does and likely to stand the test of time.




On 9/14/2018 1:09 PM, Stuart Marks wrote:
>
> First, naming. I think "duplex" as the root word wins! Using 
> "duplexing" to conform to many of other collectors is fine; so, 
> "duplexing" is good. 


From jonathan.gibbons at oracle.com  Sat Sep 15 17:04:12 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sat, 15 Sep 2018 10:04:12 -0700
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <ae1e2c94-12d4-ece7-0775-4c72318e95ea@gmail.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <ae1e2c94-12d4-ece7-0775-4c72318e95ea@gmail.com>
Message-ID: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com>

Jaikiran,

This issue is on our radar; there is no need for any additional action
on your part at this point.

-- Jon


On 9/14/18 7:50 PM, Jaikiran Pai wrote:
> Hello Peter,
>
>
> On 14/09/18 1:03 PM, Peter Levart wrote:
>> The check for main class is performed after compilation (which
>> actually produces the main class name).
>>
>> I think it would be possible to check for all classes compiled from
>> the source file after compilation without to much complication. The
>> compilation produces classes and stores them into a Map<String,
>> byte[]>. The keySet() of that map is a Set of compiled class names.
>> Each of them could be tested via .getResource() invoked upon the
>> application class loader. The error could even point to the URL of the
>> conflicting class file that way...
>>
> Thank you for moving this to the correct mailing list. Thanks for those
> details about how it's done and what can be done to improve this. Should
> I report this as an enhancement request at bugs.java.com? I don't have
> access to the OpenJDK JIRA for creating this request there.
>
> -Jaikiran


From martin.desruisseaux at geomatys.com  Sat Sep 15 18:16:45 2018
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Sat, 15 Sep 2018 20:16:45 +0200
Subject: Thought on multiplicity of properties in Java
Message-ID: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>

I?m deriving Java interfaces from the UML of ISO 19111 international
standard, and a though come to my mind. This is not a request for
changing anything in the Java language now, I?m just wondering if this
is something worth to be considered for the future. This proposal would
require javac to handle Optional<Foo> and maybe Collection<Foo> method
return types in a special way, but would not require JVM change in my
understanding.

Sometime a property is optional in a parent class, but become mandatory
in some subclasses. In UML, the [0?1] multiplicity in parent class
become restricted to [1?1] multiplicity in subclasses. I wonder if javac
could do a special case for catching this model as below. Allow to override:

    class Parent {
    ??? Optional<Foo> getFoo();
    }

with:

    class Child extends Parent {
    ??? @MaybeSomeAnnotationMakingIntentClear
    ??? @Override
    ??? Foo getFoo();
    }

Those two methods differ only by the return type, which I think is
allowed at the JVM level. In the Child class, javac would generate the
following synthetic method:

    @Override
    final Optional<Foo> getFoo() {
    ??? return Optional.of(getFoo());????? // Invoke the getFoo() method that return Foo.
    }

Subclasses of Child can override only the method returning Foo, not
Optional<Foo>. In UML parlance, the [0?1] multiplicity can be restricted
to [1?1] but the converse is not allowed (this is the same reasoning
than method return type covariance in Java, applied to multiplicity
instead than type). Invocation of getFoo() on Parent class would invoke
the methods returning Optional<Foo>, while invocation of getFoo() on
Child class would invoke the method returning Foo. Whether the following
should be a compiler error or not is an open question:

    Child a = ...;
    Optional<Foo> foo = a.getFoo();

Something similar could be done for method returning Collection<Foo>
too, if we consider those methods as properties having a [0??]
multiplicity which can be restricted to [0?1] or [1?1] multiplicity in
subclasses. In summary, Java already has type covariance and I wonder if
it could be extended to "multiplicity covariance" with javac handling
Collection<Foo> as [0??], Optional<Foo> as [0?1] and Foo as [1?1]. I'm
of course not asking for any action; just curious if it is worth to put
on a list of possible future Java evolutions.

??? Regards,

??? ??? Martin



From philip.race at oracle.com  Sat Sep 15 20:59:22 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 15 Sep 2018 13:59:22 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <a00c5e09-5839-7212-3355-0fc7db5ce169@oracle.com>
 <dcb41fa5-fc06-bf15-d059-ab5fecfdeb84@oracle.com>
Message-ID: <5B9D72AA.9060507@oracle.com>

Were people mis-reading this as java.desktop ?

Yes, its fine,  this was added under 
https://bugs.openjdk.java.net/browse/JDK-8055206
and we should have removed that when jdk.desktop was backed out
under https://bugs.openjdk.java.net/browse/JDK-8173409

-phil.

On 9/14/18, 11:41 AM, Sean Mullan wrote:
> On 9/13/18 7:52 PM, Stuart Marks wrote:
>> I'd guess that security-dev would have reviewers for the change to 
>> default.policy. Cc'd.
>
> The default.policy file change looks like this is not specifically 
> related to this change because the jdk.desktop module no longer 
> exists. I guess it is ok to include it with this change but I think 
> someone else (maybe Phil Race) should double-check that is ok.
>
> --Sean
>>
>> s'marks
>>
>> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review fix for jdk12.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>>
>>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>>
>>> During development of jdk9 it was considered that this API is not 
>>> supported and may be removed in the future: JDK-8051640.
>>> In jdk11 this class was marked as "forRemoval = true" (see 
>>> JDK-8205588) and can be dropped in 12.
>>>
>>> In the fix these things were removed:
>>>   - com/sun/awt/SecurityWarning.java
>>>   - The test for SecurityWarning class
>>>   - Test groups, because SecurityWarning is the latest class in 
>>> "com/sun/awt" package
>>>   - The reference to "com/sun/awt" in the "default.policy"
>>>
>>> (cc) core-libs-dev:
>>> I am not sure who is responsible to review the change in 
>>> "default.policy".
>>>
>>>

From philip.race at oracle.com  Sat Sep 15 21:00:48 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 15 Sep 2018 14:00:48 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
Message-ID: <5B9D7300.8080207@oracle.com>

It was exported  in the past .. and it was publicly documented ..

http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html

.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.

+1

-phil.

On 9/13/18, 7:20 PM, mandy chung wrote:
>
> On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review fix for jdk12.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
>> Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
>>
>
> Thus change looks okay to me.  This class is not exported
> and so I have updated the CSR of "Implementation" scope rather
> than JDK.
>
> Mandy
>
>> The client code has a "com.sun.awt.SecurityWarning" class which at 
>> some point in the past, JDK 6u10, was used as a kind of "public" API.
>>
>> During development of jdk9 it was considered that this API is not 
>> supported and may be removed in the future: JDK-8051640.
>> In jdk11 this class was marked as "forRemoval = true" (see 
>> JDK-8205588) and can be dropped in 12.
>>
>> In the fix these things were removed:
>>  - com/sun/awt/SecurityWarning.java
>>  - The test for SecurityWarning class
>>  - Test groups, because SecurityWarning is the latest class in 
>> "com/sun/awt" package
>>  - The reference to "com/sun/awt" in the "default.policy"
>>
>> (cc) core-libs-dev:
>> I am not sure who is responsible to review the change in 
>> "default.policy".
>>
>>
>

From jai.forums2013 at gmail.com  Sun Sep 16 02:31:21 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 16 Sep 2018 08:01:21 +0530
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <ae1e2c94-12d4-ece7-0775-4c72318e95ea@gmail.com>
 <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com>
Message-ID: <b9a9c65d-13e3-df4d-c6a8-e4e9cdd692ef@gmail.com>

Thank you Jon.

-Jaikiran


On 15/09/18 10:34 PM, Jonathan Gibbons wrote:
> Jaikiran,
>
> This issue is on our radar; there is no need for any additional action
> on your part at this point.
>
> -- Jon
>
>
> On 9/14/18 7:50 PM, Jaikiran Pai wrote:
>> Hello Peter,
>>
>>
>> On 14/09/18 1:03 PM, Peter Levart wrote:
>>> The check for main class is performed after compilation (which
>>> actually produces the main class name).
>>>
>>> I think it would be possible to check for all classes compiled from
>>> the source file after compilation without to much complication. The
>>> compilation produces classes and stores them into a Map<String,
>>> byte[]>. The keySet() of that map is a Set of compiled class names.
>>> Each of them could be tested via .getResource() invoked upon the
>>> application class loader. The error could even point to the URL of the
>>> conflicting class file that way...
>>>
>> Thank you for moving this to the correct mailing list. Thanks for those
>> details about how it's done and what can be done to improve this. Should
>> I report this as an enhancement request at bugs.java.com? I don't have
>> access to the OpenJDK JIRA for creating this request there.
>>
>> -Jaikiran
>


From info at j-kuhn.de  Fri Sep 14 19:34:10 2018
From: info at j-kuhn.de (Johannes Kuhn)
Date: Fri, 14 Sep 2018 21:34:10 +0200
Subject: [JDK-8209078] Unable to call default interface methods from named
 module
Message-ID: <5f272ab7-cd72-faaa-2705-d676671ab8e7@j-kuhn.de>

Hi everyone,

I recently reported JDK-8209078 "Unable to call default method from
interface in another module from named module" [1].

It is possible to call any default interface method directly using
MethodHandles.lookup().findSpecial(Interf.class, "defaultMethodName",
..., Intef.class).invoke(...);

This only works if the caller is in an unnamed module or Interf is in
the same module as the caller.

I now want to share some thoughts about this feature, and an idea how it
could be fixed, but this probably requires further discussion.

1. Use Case:

The most obvious use case is to to "implement" default methods in
instances created by j.l.r.Proxy. An implementation of
j.l.r.InvocationHandler that handles default methods could look like this:

    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        if (method.isDefault()) {
            MethodType mt = methodType(method.getReturnType(),
                    method.getParameterTypes());
            Class<?> declaringClass = method.getDeclaringClass();
            Lookup l = MethodHandles.lookup();
            MethodHandle mh = l.findSpecial(declaringClass,
                    method.getName(), mt, declaringClass)
                   .asFixedArity()
                   .bindTo(proxy);
            return mh.invokeWithArguments(args);
        }
    // Handle the other methods
    return null;
    }

Such a feature is very valuable so the InvocationHandler does not break
if an interface is evolved by adding new default methods.

2. Documentation:

When I faced the problem above, I did a search on how to invoke default
methods on a proxy.

The above code was inspired by this mail [2] from John Rose, where he
mentions JDK-8130227 "JEP 274: Enhanced Method Handles" [3][4].

This is the only official documentation I could find on this feature.

Indeed, even the Javadoc for findSpecial [5] states that my code above
should not successfully run:

> Before method resolution, if the explicitly specified caller class is
> not identical with the lookup class, or if this lookup object does not
> have private access privileges, the access fails.

The specified caller class in the example above is the interface itself,
not the lookup class.

The documentation has to be at least changed to reflect this feature.

3. Cause of the discrepancy between lookup class in named module vs
unnamed module

As Mandy Chung observed:

> IAE is thrown because the implementation calls Lookup::in teleporting
> to a Lookup of the special class which lost all access since the
> caller class and the requested lookup class are in different modules.

This behavior is documented in the Lookup.in() [6]:

> * If the old lookup class is in a named module, and the new lookup
> class is in a different module M, then no members, not even public
> members in M's exported packages, will be accessible. The exception to
> this is when this lookup is publicLookup, in which case PUBLIC access
> is not lost.
> * If the old lookup class is in an unnamed module, and the new lookup
> class is a different module then MODULE access is lost.

This strikes me as a little bit odd, so I looked around for the
reasoning for this difference, and found an old discussion on jigsaw-dev
[7]. I especially found this mail from Alan Bateman [8] interesting,
where he gave a reasoning for this:

> Preserved but perhaps with the (initially surprising) consequence that
> all access is lost when m(LC) is a named module and m(A) is a
> different module. This arises because the two modules may read very
> different sets of modules, the intersection cannot be expressed via a
> lookup class + modes.

While I agree that intersection might not be expressed via lookup class
+ modes, I don't think that it is necessary to express that. Instead
don't allow any lookup on members in a different module if the MODULE
flag is not set.

But this is only a suggestion. It's up to you to decide how to deal with
this.

Please keep up the good work you are doing, and I hope this mail will
help you fixing this bug.

Thanks for your time,
Johannes Kuhn

[1]: https://bugs.openjdk.java.net/browse/JDK-8209078
[2]:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010741.html
[3]: https://bugs.openjdk.java.net/browse/JDK-8130227
[4]: http://openjdk.java.net/jeps/274
[5]:
https://docs.oracle.com/javase/10/docs/api/java/lang/invoke/MethodHandles.Lookup.html#findSpecial(java.lang.Class,java.lang.String,java.lang.invoke.MethodType,java.lang.Class)
[6]:
https://docs.oracle.com/javase/10/docs/api/java/lang/invoke/MethodHandles.Lookup.html#in(java.lang.Class)
[7]:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005751.html
[8]:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005768.html

From xueming.shen at oracle.com  Sun Sep 16 07:06:00 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 16 Sep 2018 00:06:00 -0700
Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip file
 is located in a custom file system
Message-ID: <5B9E00D8.8020505@oracle.com>

Hi

Please help review the change for JDK-8034802.

issue: https://bugs.openjdk.java.net/browse/JDK-8034802
webrev: http://cr.openjdk.java.net/~sherman/8034802/webrev

One of the reasons that the implementation works this way is that I 
didn't have a
complete SeekableByteChannel support (mainly the position(...)) from 
newByteChannel()
back then (so you really can't get a ZipFileSystem from a jar/zip file 
inside a zfs :-))

So this changeset also includes a ByteArrayChannel which implements SBC 
and has
better position()/position(int) support, and now we can have a zipfs 
from a zip file
inside a zipfs.

Thanks,
Sherman



From Alan.Bateman at oracle.com  Sun Sep 16 07:48:57 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Sep 2018 08:48:57 +0100
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <5B9D7300.8080207@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
 <5B9D7300.8080207@oracle.com>
Message-ID: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>

On 15/09/2018 22:00, Philip Race wrote:
> It was exported? in the past .. and it was publicly documented ..
>
> http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
>
> .. so I think Sergey was correct in his "JDK" scope.
> Implementation would be for something entirely internal.
I think Sergey's changes are okay.

The main issue with com.sun.awt API is that it tried to be both an 
exported and internal/unsupported API at the same time (it's javadoc 
reads "This class is an implementation detail and only meant for limited 
use outside of the core platform"). This doesn't work for modules. In 
addition the design principles in JEP 200 make it clear that standard 
modules should not export a non-standard package to all modules. If 
there has been extensive use of this API then I could imagine it being 
refactored and moved into a JDK-specific module but there was little 
evidence of usage. So where we ended up in JDK 9 is that the API is not 
exported. This means, as Mandy hinted, you can't compile against this 
API (at least not without --add-exports to the compiler). Existing code 
using this API will continue to run on JDK 9, 10, 11 or until the 
java.desktop module is fully encapsulated or the SecurityWarning class 
is removed. Sergey got there first.

-Alan

From Alan.Bateman at oracle.com  Sun Sep 16 09:15:28 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Sep 2018 10:15:28 +0100
Subject: [JDK-8209078] Unable to call default interface methods from named
 module
In-Reply-To: <5f272ab7-cd72-faaa-2705-d676671ab8e7@j-kuhn.de>
References: <5f272ab7-cd72-faaa-2705-d676671ab8e7@j-kuhn.de>
Message-ID: <a92c5150-452f-c54c-21a1-71386f4d412b@oracle.com>

On 14/09/2018 20:34, Johannes Kuhn wrote:
> :
>
> 1. Use Case:
>
> The most obvious use case is to to "implement" default methods in
> instances created by j.l.r.Proxy. An implementation of
> j.l.r.InvocationHandler that handles default methods could look like this:
>
>      public Object invoke(Object proxy, Method method, Object[] args)
>              throws Throwable {
>          if (method.isDefault()) {
>              MethodType mt = methodType(method.getReturnType(),
>                      method.getParameterTypes());
>              Class<?> declaringClass = method.getDeclaringClass();
>              Lookup l = MethodHandles.lookup();
>              MethodHandle mh = l.findSpecial(declaringClass,
>                      method.getName(), mt, declaringClass)
>                     .asFixedArity()
>                     .bindTo(proxy);
>              return mh.invokeWithArguments(args);
>          }
>      // Handle the other methods
>      return null;
>      }
>
> Such a feature is very valuable so the InvocationHandler does not break
> if an interface is evolved by adding new default methods.
The common case will be a public interface in an exported package in 
which case the proxy will be generated in the unnamed module of the 
specified class loader. This means you can create a full-power lookup on 
the proxy class with:

Class<?> proxyClass = proxy.getClass();
this.getClass().getModule().addReads(proxyClass.getModule());
Lookup l = MethodHandles.privateLookupIn(proxyClass, 
MethodHandles.lookup());

If you invoke findSpecial on this lookup then I would expect it should work.

There can be cases where the proxy is encapsulated (because the 
interfaces are not public or not in exported packages) but I assume you 
don't need to be concerned with those for now.

> :
>
>
> 3. Cause of the discrepancy between lookup class in named module vs
> unnamed module
>
> As Mandy Chung observed:
>
>> IAE is thrown because the implementation calls Lookup::in teleporting
>> to a Lookup of the special class which lost all access since the
>> caller class and the requested lookup class are in different modules.
> This behavior is documented in the Lookup.in() [6]:
>
>> * If the old lookup class is in a named module, and the new lookup
>> class is in a different module M, then no members, not even public
>> members in M's exported packages, will be accessible. The exception to
>> this is when this lookup is publicLookup, in which case PUBLIC access
>> is not lost.
>> * If the old lookup class is in an unnamed module, and the new lookup
>> class is a different module then MODULE access is lost.
> This strikes me as a little bit odd, so I looked around for the
> reasoning for this difference, and found an old discussion on jigsaw-dev
> [7]. I especially found this mail from Alan Bateman [8] interesting,
> where he gave a reasoning for this:
>
>> Preserved but perhaps with the (initially surprising) consequence that
>> all access is lost when m(LC) is a named module and m(A) is a
>> different module. This arises because the two modules may read very
>> different sets of modules, the intersection cannot be expressed via a
>> lookup class + modes.
> While I agree that intersection might not be expressed via lookup class
> + modes, I don't think that it is necessary to express that. Instead
> don't allow any lookup on members in a different module if the MODULE
> flag is not set.
>
Qualified exports complicated this, as does readability. JDK-8173978 [1] 
tracks the need to support checking the intersection.

-Alan

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




From amaembo at gmail.com  Sun Sep 16 09:23:34 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Sun, 16 Sep 2018 16:23:34 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <5fe26010-e5dd-3cc4-35ac-6260011c2172@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
Message-ID: <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>

Hello, Brian!

Regarding more than two collectors. Some libraries definitely have
analogs (e.g. [1]) which combine more than two collectors. To my
opinion combining two collectors this way is an upper limit for
readable code. Especially if you are going to collect to the list, you
will have a list of untyped and unnamed results which positionally
correspond to the collectors. If you have more than two collectors to
combine, writing a separate accumulator class with accept/combine
methods and creating a collector from the scratch would be much easier
to read and support. A good example is IntSummaryStatistics and the
corresponding summarizingInt collector. It could be emulated combining
four collectors (maxBy, minBy, summingInt, counting), but having a
dedicated class IntSummaryStatistics which does all four things
explicitly is much better. It could be easily reused outside of Stream
API context, it has well-named and well-typed accessor methods and it
may contain other domain-specific methods like average(). Imagine if
it were a List of four elements and you had to call summary.get(1) to
get a maximum. So I think that supporting more than two collectors
would encourage obscure programming.

With best regards,
Tagir Valeev

[1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
(don't ask me why!)

On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
> to be a name we regret, for reasons outlined below.
>
>
> The behavior of this Collector is:
>   - duplicate the stream into two identical streams
>   - collect the two streams with two collectors, yielding two results
>   - merge the two results into a single result
>
> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
> entirely accurate and explanatory, is "a bit" unwieldy.  So the
> questions are:
>   - how much can we drop and still be accurate
>   - which parts are best to drop.
>
> When we pick names, we are not just trying to pick the best name for
> now, but we should imagine all the possible operations one might ever
> want to do in the future (names in the JDK are forever) and make a
> reasonable attempt to imagine whether this could cause confusion or
> regret in the future.
>
> To evaluate "duplexing" here (which seems the most important thing to
> keep), I'd ask: is there any other reasonable way to imagine a
> `duplexing` collect operation, now or in the future?
>
> One could imagine wanting an operation that takes a stream and produces
> two streams whose contents are that of the original stream.  And
> "duplex" is a good name for that.  But, it is not a Collector; it would
> be a stream transform, like concat.  So that doesn't seem a conflict; a
> duplexing collector and a duplexing stream transform are sort of from
> "different namespaces."
>
> Can one imagine a "duplexing" Collector that doesn't do any collection?
> I cannot.  Something that returns a pair of streams would not be a
> Collector, but something else. So dropping AndCollecting seems justified.
>
> What about "AndThenMerging"?  The purpose of collect is to reduce the
> stream into a summary description.  Can we imagine a duplexing operation
> that doesn't merge the two results, but instead just returns a tuple of
> the results?  Yes, I can totally imagine this, especially once we have
> value types and records, which makes returning ad-hoc tuples cheaper
> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
> reasonable possibility. But, I would have no problem with an overload
> that didn't take a merger and returned a tuple of the result, and was
> still called `duplexing`.
>
> So I'm fine with dropping all the extra AndThisAndThat.
>
> Finally, there's one other obvious direction we might extend this --
> more than two collectors.  There's no reason why we can only do two; we
> could take a (likely homogeneous) varargs of Collectors, and return a
> List of results -- which itself could then be streamed into another
> collector.  This actually sounds pretty useful (though I'm not
> suggesting doing this right now.) And, I think it would be silly if this
> were not called the same thing as the two-collector version (just as it
> would be silly to have separate names for "concat two" and "concat n".)
>
> And, this is where I think "duplexing" runs out of gas -- duplex implies
> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
> "tee" also has bilateral symmetry, but I don't think you could
> reasonably argue that a four-way "tee" is not less of an arity abuse
> than a four-way "duplex", and the plumbing industry would agree:
>
> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
>
> So, for these reasons, I still think "teeing" has a better balance of
> being both evocative what it does and likely to stand the test of time.
>
>
>
>
> On 9/14/2018 1:09 PM, Stuart Marks wrote:
> >
> > First, naming. I think "duplex" as the root word wins! Using
> > "duplexing" to conform to many of other collectors is fine; so,
> > "duplexing" is good.
>

From Alan.Bateman at oracle.com  Sun Sep 16 13:03:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Sep 2018 14:03:18 +0100
Subject: 8210496: Improve filtering for classes with security sensitive
 fields
In-Reply-To: <ba5b578f-6908-25dc-b2ba-db2165495971@gmail.com>
References: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
 <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
 <ba5b578f-6908-25dc-b2ba-db2165495971@gmail.com>
Message-ID: <8b21c1d7-05a9-2cf4-d730-a7a48d976ccb@oracle.com>

On 14/09/2018 20:16, Peter Levart wrote:
> Hi Alan,
>
> Just a few comments about implementation.
>
> In Reflection:
>
> ?292???????????? boolean shouldSkip = false;
> ?293???????????? for (String filteredName : filteredNames) {
> ?294???????????????? if (member.getName() == filteredName) {
> ?295???????????????????? shouldSkip = true;
> ?296???????????????????? break;
> ?297???????????????? }
> ?298???????????? }
>
> ...now that filteredNames is a Set<String>, you could simplify this 
> loop to:
>
> ??? ??? shouldSkip = filteredNames.contains(member.getName());
I was trying to keep the changes to the filtering implementation as 
minimal as possible but you are right that replace the array with a set 
means the loop can be replaced (thanks!).

>
> :
>
> I don't know if it's better, but you could use just the immutable Map 
> without HashMap. Instead of:
>
> ?262???????? map = new HashMap<>(map);
> ?263???????? map.put(containingClass, Set.copyOf(names));
> ?264???????? return map;
>
> you could do this:
>
> ??????? @SuppressWarnings("unchecked")
> ??????? Map.Entry<Class<?>, Set<String>>[] entries = 
> map.entrySet().toArray(new Map.Entry[map.size() + 1]);
> ??????? entries[entries.length - 1] = Map.entry(containingClass, 
> Set.copyOf(names));
> ??????? return Map.ofEntries(entries);
>
> This should work because the registerFilter method is called at most 
> once per map/containingClass.
The existing code is easy to read. Using an immutable map has a few 
advantages but using map entries is easy to get wrong. I think I'll 
leave it as is for now.? There are a few additional classes that should 
also be added to the filter in another round so that might be the time 
to re-visit it.

I've put a new webrev here, the only change is the replacement of the 
old loop to use contains as you suggested:
 ? http://cr.openjdk.java.net/~alanb/8210496/2/webrev/index.html

-Alan


From t.linkowski at gmail.com  Sun Sep 16 20:12:15 2018
From: t.linkowski at gmail.com (Tomasz Linkowski)
Date: Sun, 16 Sep 2018 22:12:15 +0200
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
 <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>
Message-ID: <CAD4YxQUJWyQ9_+z5wHDGMLyt47Z-CvS3ZC+jvn9Y1Tg5sk47Gg@mail.gmail.com>

I agree with Tagir that supporting more than two Collectors sounds risky. I
especially agree that well-typed and well-named accessors are important.

I use the quoted library (jOOL), but I:
- either avoid all those tuple-based functions,
- or I use only Tuple2/Tuple3 and I map the tuple to a dedicated result
type immediately (with Collectors.collectingAndThen) so that I get
well-named accessors.

Note that if you need to combine more than two (generally, N) collectors,
you can just call duplexing() N-1 times and use intermediate result
holders, like I did for N=3 in [1]. It may be a bit of boilerplate, but the
only *other* way to do it without tuples in a well-typed manner for N=3 would
be to introduce a new functional interface like TriFunction<T,U,V,R> as a
merger.

That said, I found Brian's line of reasoning about dropping name parts very
convincing, and I really liked the analogy to a 4-way tee in plumbing.

Finally, here's a summary of the characteristics of the possible results
types for n-ary *heterogeneous* Collector composition:
- List<?> => well-typed: NO, well-named: NO
- n-ary tuple => well-typed: YES, well-named: NO
- custom result holder => well-typed: YES, well-named: YES

Personally, I don't find n-ary *homogeneous* Collector composition that
much useful, but if it were to be added, I agree List<T> would be the best
result type.

Regards,
Tomasz Linkowski

[1] https://stackoverflow.com/a/52211175/2032415


On Sun, Sep 16, 2018 at 11:23 AM, Tagir Valeev <amaembo at gmail.com> wrote:

> Hello, Brian!
>
> Regarding more than two collectors. Some libraries definitely have
> analogs (e.g. [1]) which combine more than two collectors. To my
> opinion combining two collectors this way is an upper limit for
> readable code. Especially if you are going to collect to the list, you
> will have a list of untyped and unnamed results which positionally
> correspond to the collectors. If you have more than two collectors to
> combine, writing a separate accumulator class with accept/combine
> methods and creating a collector from the scratch would be much easier
> to read and support. A good example is IntSummaryStatistics and the
> corresponding summarizingInt collector. It could be emulated combining
> four collectors (maxBy, minBy, summingInt, counting), but having a
> dedicated class IntSummaryStatistics which does all four things
> explicitly is much better. It could be easily reused outside of Stream
> API context, it has well-named and well-typed accessor methods and it
> may contain other domain-specific methods like average(). Imagine if
> it were a List of four elements and you had to call summary.get(1) to
> get a maximum. So I think that supporting more than two collectors
> would encourage obscure programming.
>
> With best regards,
> Tagir Valeev
>
> [1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae
> 2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
> (don't ask me why!)
>
> On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> > tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
> > to be a name we regret, for reasons outlined below.
> >
> >
> > The behavior of this Collector is:
> >   - duplicate the stream into two identical streams
> >   - collect the two streams with two collectors, yielding two results
> >   - merge the two results into a single result
> >
> > Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
> > entirely accurate and explanatory, is "a bit" unwieldy.  So the
> > questions are:
> >   - how much can we drop and still be accurate
> >   - which parts are best to drop.
> >
> > When we pick names, we are not just trying to pick the best name for
> > now, but we should imagine all the possible operations one might ever
> > want to do in the future (names in the JDK are forever) and make a
> > reasonable attempt to imagine whether this could cause confusion or
> > regret in the future.
> >
> > To evaluate "duplexing" here (which seems the most important thing to
> > keep), I'd ask: is there any other reasonable way to imagine a
> > `duplexing` collect operation, now or in the future?
> >
> > One could imagine wanting an operation that takes a stream and produces
> > two streams whose contents are that of the original stream.  And
> > "duplex" is a good name for that.  But, it is not a Collector; it would
> > be a stream transform, like concat.  So that doesn't seem a conflict; a
> > duplexing collector and a duplexing stream transform are sort of from
> > "different namespaces."
> >
> > Can one imagine a "duplexing" Collector that doesn't do any collection?
> > I cannot.  Something that returns a pair of streams would not be a
> > Collector, but something else. So dropping AndCollecting seems justified.
> >
> > What about "AndThenMerging"?  The purpose of collect is to reduce the
> > stream into a summary description.  Can we imagine a duplexing operation
> > that doesn't merge the two results, but instead just returns a tuple of
> > the results?  Yes, I can totally imagine this, especially once we have
> > value types and records, which makes returning ad-hoc tuples cheaper
> > (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
> > reasonable possibility. But, I would have no problem with an overload
> > that didn't take a merger and returned a tuple of the result, and was
> > still called `duplexing`.
> >
> > So I'm fine with dropping all the extra AndThisAndThat.
> >
> > Finally, there's one other obvious direction we might extend this --
> > more than two collectors.  There's no reason why we can only do two; we
> > could take a (likely homogeneous) varargs of Collectors, and return a
> > List of results -- which itself could then be streamed into another
> > collector.  This actually sounds pretty useful (though I'm not
> > suggesting doing this right now.) And, I think it would be silly if this
> > were not called the same thing as the two-collector version (just as it
> > would be silly to have separate names for "concat two" and "concat n".)
> >
> > And, this is where I think "duplexing" runs out of gas -- duplex implies
> > "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
> > "tee" also has bilateral symmetry, but I don't think you could
> > reasonably argue that a four-way "tee" is not less of an arity abuse
> > than a four-way "duplex", and the plumbing industry would agree:
> >
> > https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
> >
> > So, for these reasons, I still think "teeing" has a better balance of
> > being both evocative what it does and likely to stand the test of time.
> >
> >
> >
> >
> > On 9/14/2018 1:09 PM, Stuart Marks wrote:
> > >
> > > First, naming. I think "duplex" as the root word wins! Using
> > > "duplexing" to conform to many of other collectors is fine; so,
> > > "duplexing" is good.
> >
>



-- 
Pozdrawiam,
Tomasz Linkowski

From forax at univ-mlv.fr  Sun Sep 16 22:54:59 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 17 Sep 2018 00:54:59 +0200 (CEST)
Subject: Thought on multiplicity of properties in Java
In-Reply-To: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>
References: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>
Message-ID: <1876540140.5154.1537138499879.JavaMail.zimbra@u-pem.fr>

Hi Martin,

----- Mail original -----
> De: "Martin Desruisseaux" <martin.desruisseaux at geomatys.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 15 Septembre 2018 20:16:45
> Objet: Thought on multiplicity of properties in Java

> I?m deriving Java interfaces from the UML of ISO 19111 international
> standard, and a though come to my mind. This is not a request for
> changing anything in the Java language now, I?m just wondering if this
> is something worth to be considered for the future. This proposal would
> require javac to handle Optional<Foo> and maybe Collection<Foo> method
> return types in a special way, but would not require JVM change in my
> understanding.
> 
> Sometime a property is optional in a parent class, but become mandatory
> in some subclasses. In UML, the [0?1] multiplicity in parent class
> become restricted to [1?1] multiplicity in subclasses. I wonder if javac
> could do a special case for catching this model as below. Allow to override:
> 
>    class Parent {
>    ??? Optional<Foo> getFoo();
>    }
> 
> with:
> 
>    class Child extends Parent {
>    ??? @MaybeSomeAnnotationMakingIntentClear
>    ??? @Override
>    ??? Foo getFoo();
>    }
> 
> Those two methods differ only by the return type, which I think is
> allowed at the JVM level. In the Child class, javac would generate the
> following synthetic method:
> 
>    @Override
>    final Optional<Foo> getFoo() {
>    ??? return Optional.of(getFoo());????? // Invoke the getFoo() method that return
>    ??? Foo.
>    }
> 
> Subclasses of Child can override only the method returning Foo, not
> Optional<Foo>. In UML parlance, the [0?1] multiplicity can be restricted
> to [1?1] but the converse is not allowed (this is the same reasoning
> than method return type covariance in Java, applied to multiplicity
> instead than type). Invocation of getFoo() on Parent class would invoke
> the methods returning Optional<Foo>, while invocation of getFoo() on
> Child class would invoke the method returning Foo. Whether the following
> should be a compiler error or not is an open question:
> 
>    Child a = ...;
>    Optional<Foo> foo = a.getFoo();
> 
> Something similar could be done for method returning Collection<Foo>
> too, if we consider those methods as properties having a [0??]
> multiplicity which can be restricted to [0?1] or [1?1] multiplicity in
> subclasses. In summary, Java already has type covariance and I wonder if
> it could be extended to "multiplicity covariance" with javac handling
> Collection<Foo> as [0??], Optional<Foo> as [0?1] and Foo as [1?1]. I'm
> of course not asking for any action; just curious if it is worth to put
> on a list of possible future Java evolutions.


The Java spec limit covariance to subtyping relationship only (there is no covariance between primitive types, or between a primitive type and it's corresponding wrapper), so you can not use Java to implement overriding of UML properties with different multiplicity. 
But if you generate the bytecode instead of generating Java code to generate the interfaces, you are not limited by the Java spec, so you can generate the bridge methods you want.

> 
>??? Regards,
> 
> ??? ??? Martin

regards,
R?mi

From xu.y.yin at oracle.com  Mon Sep 17 01:23:07 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Mon, 17 Sep 2018 09:23:07 +0800
Subject: [12] RFR 8210695: Create test to cover JDK-8205330
 InitialDirContext ctor sometimes throws NPE if the server has sent a
 disconnection
In-Reply-To: <0b1d63ee-4b6d-1f07-a1ea-dc6a557c5e04@oracle.com>
References: <1969EF7D-D7C6-4AE1-8A2B-42B554656250@oracle.com>
 <02180a46-41cd-3e66-59e0-3738fa4180ae@oracle.com>
 <C4515F6A-A9A2-4984-83ED-F88B0D13225E@oracle.com>
 <0b1d63ee-4b6d-1f07-a1ea-dc6a557c5e04@oracle.com>
Message-ID: <FDB3EC07-78F2-474B-9C9A-70C995A43816@oracle.com>

Thank you, Daniel

Regards,
Chris

> On 14 Sep 2018, at 6:19 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> > http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
> 
> Looks good to me.
> 
> > Yep, fixed as you suggested. My original though is that the stack trace maybe too verbose if most of runs hit NamingException, leave it to stderr may make the log more readable, but yes, the exception is expected and not considered as error as you commented. Anyway, we could adjust it later if necessary.
> 
> An alternative then would be to print an additional message on
> stderr - something like:
> 
>  89                 } catch (NamingException ne) {
>  90                     System.out.println("(" + count + "/" + REPEAT_COUNT
>  91                             + ") It's ok to get NamingException: " + ne);
>  92                     // for debug
>                         System.err.println("Caught expected exception: " + ne);
>  93                     ne.printStackTrace();
> 
> If you decide to go this way instead then no need for an additional
> review...
> 
> best regards,
> 
> -- daniel
> 
> 
> 
> On 14/09/2018 04:42, Chris Yin wrote:
>> Hi, Daniel
>> Thank you for the reviewing and comments, inline and update webrev as below, thanks
>> http://cr.openjdk.java.net/~xyin/8210695/webrev.01/
>>> On 13 Sep 2018, at 5:43 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Thanks a lot for writing this test!
>>> 
>>>  60         serverSocket = new ServerSocket(0);
>>>  69         env.put(Context.PROVIDER_URL, String.format("ldap://localhost:%d/",
>>> 
>>> For robustness of the test I would suggest using
>>> InetAddress.getLoopbackAddress() explicitly, to
>>> avoid having the dummy server listen on all interfaces.
>>> Listening on all interfaces has proved to be a source of
>>> intermittent failures in the past, possibly due
>>> to different port reuse strategies at OS level.
>> Sure, fixed, thanks
>>> 
>>>  88                     System.out.println("(" + count + "/" + REPEAT_COUNT
>>>  89                             + ") It's ok to get NamingException: " + ne);
>>>  90                     // for debug
>>>  91                     ne.printStackTrace();
>>> 
>>> I think it would be better in that case to print the stactrace on
>>> stdout (i.e. use ne.printStackTrace(System.out)), since that
>>> exception is expected and not considered as an error.
>> Yep, fixed as you suggested. My original though is that the stack trace maybe too verbose if most of runs hit NamingException, leave it to stderr may make the log more readable, but yes, the exception is expected and not considered as error as you commented. Anyway, we could adjust it later if necessary.
>> Regards,
>> Chris
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>> 
>>> On 13/09/2018 07:59, Chris Yin wrote:
>>>> Please have a review for below new added test to cover JDK-8205330, thanks
>>>> This test used dummy ldap server to simulate the scenario to send ?Notice of Disconnection? after binding, it will repeat InitialDirContext() for 1000 times (normally the NPE bug should be hit less than 100 times run, but just in case), test failed with NPE if without JDK-8205330 fix change and passed after the fix.
>>>> I put this test under test/jdk/com/sun/jndi/ldap/ since the bug root cause is from com.sun.jndi.ldap.LdapClient, feel free to let me know if it should be moved to other suitable folder.
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210695
>>>> webrev: http://cr.openjdk.java.net/~xyin/8210695/webrev.00/
>>>> Regards,
>>>> Chris
>>> 
> 


From frank.yuan at oracle.com  Mon Sep 17 07:12:21 2018
From: frank.yuan at oracle.com (Frank Yuan)
Date: Mon, 17 Sep 2018 15:12:21 +0800
Subject: RFR (12): 8210819: Update the host name in CNameTest.java
Message-ID: <047b01d44e55$c8758a40$59609ec0$@oracle.com>

Hi

 

Would you like to review the following patch for 

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

 

--- a/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java         Wed Sep 12 21:56:59 2018 -0700

+++ b/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java      Mon Sep 17 15:00:55 2018 +0800

@@ -1,5 +1,5 @@

/*

- * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.

+ * Copyright (c) 2017, 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

@@ -38,7 +38,7 @@

  * @summary Test DNS provider's handling of CNAME records

  */

public class CNameTest {

-    private static final String HOST = "www-proxy.us.oracle.com";

+    private static final String HOST = "www.w3c.org";

 

CNameTest.java is to test DNS provider's handling of CNAME records, so the test requires dns has cname record for the hostname. The
old name is not appropriate, I would replace it with www.w3c.org <http://www.w3c.org> .

 

Thanks

Frank


From martin.desruisseaux at geomatys.com  Mon Sep 17 08:21:50 2018
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Mon, 17 Sep 2018 10:21:50 +0200
Subject: Thought on multiplicity of properties in Java
In-Reply-To: <1876540140.5154.1537138499879.JavaMail.zimbra@u-pem.fr>
References: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>
 <1876540140.5154.1537138499879.JavaMail.zimbra@u-pem.fr>
Message-ID: <ec6ef0ad-0027-0176-3e83-3b01b9a2b7b5@geomatys.com>

Hello R?mi

Thanks for your reply.

Le 17/09/2018 ? 00:54, Remi Forax a ?crit?:

> The Java spec limit covariance to subtyping relationship only (there
> is no covariance between primitive types, or between a primitive type
> and it's corresponding wrapper), so you can not use Java to implement
> overriding of UML properties with different multiplicity. But if you
> generate the bytecode instead of generating Java code to generate the
> interfaces, you are not limited by the Java spec, so you can generate
> the bridge methods you want.
>
Yes I know. My question was if "multiplicity covariance" was something
that may be worth considering at the Java language level for some future
version of the specification. This is not a request to do so, only an idea.

??? Regards,

??? ??? Martin



From daniel.fuchs at oracle.com  Mon Sep 17 10:10:16 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Sep 2018 11:10:16 +0100
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <5B9BEB24.5040605@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
 <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
 <5B9BEB24.5040605@oracle.com>
Message-ID: <a3e04203-bce0-a8b0-539a-6034831aec94@oracle.com>

Hi Joe,

hmmm... I'm not sure I'm completely convinced.

Let's take an example, and assume your input
has been split in two strings of 4 characters each
(the code I'm seeing implies that this is possible,
right?) In the sketch below the first line represents
the loop iterations, the second line represents
the two strings as char buffers (hs = high surrogate,
ls = low surrogate, x,y = just regular chars), the third
line represents index increments, and the fourth line
represents the result of the writeUTF16Surrogate method:

L1:   1   -  2    3        1      2    3   -
L2: [ hs  ls x    hs ]   [ ls     y    hs  ls ]
L3:   \i+2/  i++  i++      i++    i++  \i+2/
L4:   cp||0       -1       cp||-1      cp||0

We have two calls to writeAttrString, the first
call writes the first 4 chars string, the second
write the next 4 chars.

In the sketch above, i++ indicates a regular
increment from the loop, and i+2 indicates
where i++ must be called a second time within
the loop because two characters were consumed
in a single iteration.

So it seems to me that the only time you want to
increment the index a second time is when you read
(and wrote) both surrogate in one shot.

In the pathological case - where the surrogate pair
was split at the string limit, there will be two
calls to writeUTF16Surrogate(...). One with the
high surrogate, that will return -1, and one with
the low surrogate that will either return -1 or a
code point. And in that case you don't want to
increment i a second time - or the character
'y' will be skipped.

Am I still missing something?

best regards,

-- daniel


On 14/09/2018 18:08, Joe Wang wrote:
> Hi Daniel,
> 
> The additional advance is made when the pair has already been written, 
> which is indicated by the return value of writeUTF16Surrogate being >= 
> 0*. Encodings.isHighUTF16Surrogate(ch) therefore would be redundant.
> 
> * Note that the return value is: -1 when nothing is written, 0 when the 
> pair is written, so the condition of >= 0 means no matter there is a 
> codepoint value or not, the index increment as long as the pair is 
> written (the low surrogate is consumed).
> 
> Best,
> Joe
> 
> On 9/14/18, 3:00 AM, Daniel Fuchs wrote:
>> Hi Joe,
>>
>> Thanks for doing that - it's a far better solution.
>>
>> ToHTMLStream.java:
>>
>> 1432??? // move the index if the surrogate pair has been written.
>> 1433??? if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
>> 1434??????? i++;
>> 1435??? }
>>
>> shouldn't this be:
>>
>> 1433??? if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
>> ??????????? if (Encodings.isHighUTF16Surrogate(ch)) {
>> ??????????????? // two input characters processed, increase
>> ??????????????? // the index again.
>> ??????????????? i++;
>> ??????????? }
>>
>> IIUC you only want to increase the index if the ch was the
>> high surrogate and the function has advanced to the low
>> surrogate?
>>
>> I mean - a codepoint could have been returned if ch was the
>> low surrogate, and in that case you don't want to increase
>> the index twice as only one character has been consumed.
>>
>> I guess there's the same issue in ToStream.java at lines
>> 1154-1156 and in ToTextStream.java at line 303...
>>
>> Or am I missing something?
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 14/09/2018 04:13, Joe Wang wrote:
>>> Thanks Daniel.
>>>
>>> I changed the return of writeUTF16Surrogate so that it is clearer 
>>> within writeUTF16Surrogate when an additional index increment is 
>>> needed. Other corresponding changes are in ToHTMLStream and 
>>> ToTextStream where similar calls to the method are made. It's been an 
>>> issue in some part of JAXP impl where error or warning messages are 
>>> printed out to the console (e.g. JDK-8000621). But I kept it as is in 
>>> ToTextStream for this patch.
>>>
>>> webrev01:
>>> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev01/
>>>
>>> Best,
>>> Joe
>>>
>>> On 9/13/18, 2:23 AM, Daniel Fuchs wrote:
>>>> Hi Joe,
>>>>
>>>> On 13/09/2018 00:25, Lance Andersen wrote:
>>>>> Hi Joe,
>>>>>
>>>>> The change? seems reasonable
>>>>
>>>> Agreed. However the following condition in ToStream::handleEscaping
>>>> is a bit cryptic:
>>>>
>>>> 1155???????????? if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
>>>> 1156???????????????? i++ ; // process two input characters
>>>> 1157???????????? }
>>>>
>>>> could the comment be fleshed out to explain it?
>>>>
>>>> I suspect that: `(ihs && (i + 1 < end))` means that
>>>> `writeUTF16Surrogate(c, ch, i, end);` has written the two surrogate, in
>>>> which case i should be incremented in order to skip the low surrogate
>>>> which has just been written.
>>>>
>>>> I am not sure what `(ils && i != 0)` means, though...
>>>>
>>>> best regards
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please review a patch for a situation where a surrogate pair is at 
>>>>>> the edge of a buffer. What the existing impl did was to report it 
>>>>>> as an error. This patch fixes it by caching the high surrogate and 
>>>>>> prints it out along with the low surrogate. Similar issue exists 
>>>>>> also in the CDATA section and is fixed in this patch. The CDATA 
>>>>>> impl had a couple of bugs where an indent could be written inside 
>>>>>> the CDATA and an unicode character written in between two CDATA 
>>>>>> sections. Both are fixed in this patch.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>>>>>
>>>>>> 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 daniel.fuchs at oracle.com  Mon Sep 17 10:14:05 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Sep 2018 11:14:05 +0100
Subject: Review Request JDK-8210721: Replace legacy serial exception field
 with Throwable::cause
In-Reply-To: <0fe7b6aa-6e7c-8620-3263-3f513ae08af6@oracle.com>
References: <7fc3e581-d0ef-e097-ef8f-62ea3faf53fe@oracle.com>
 <a5c6cc8c-c6a0-5780-df46-f4bc7a4bcabc@oracle.com>
 <0fe7b6aa-6e7c-8620-3263-3f513ae08af6@oracle.com>
Message-ID: <9927123f-15d5-a8ed-fc54-148b9fade1b1@oracle.com>

On 14/09/2018 18:46, mandy chung wrote:
> Jason also caught this accidental change in a different thread [1] and also
> suggests to call super.getCause since getCause is not final and may be
> overridden.? The updated webrev is:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.01/

Looks good to me Mandy!

best regards,

-- daniel

> 
> Thanks
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055421.html
>> Obviously no need for another webrev, and no need for a new
>> fix if you pushed already...
>>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 13/09/2018 19:44, mandy chung wrote:
>>> A few exception classes such as ExceptionInInitializerError, 
>>> InvocationTargetException,
>>> etc were defined prior to the exception chaining facility and 
>>> provides the API to get
>>> the cause of the exception. These classes keep its legacy serial 
>>> field e.g.
>>> ExceptionInInitializerError::exception to get the serialization to 
>>> work on older JDK version.
>>>
>>> During the review of JDK-8209553 [1], Peter and Joe suggest to remove 
>>> this legacy
>>> serial field and implement the serialization using 
>>> serialPersistentFields, readObject
>>> and writeObject.?? It turns out that these redundant fields were 
>>> removed when the
>>> exception chaining support was initially implemented but it got 
>>> reverted to fix
>>> JDK-4385429 since Throwable::setCause rejects any further change as
>>> Throwable::cause has been initialized to null.
>>>
>>> This patch removes these legacy serial field and stores the cause in 
>>> Throwable::cause.
>>> It's essentially a redo for the fix for JDK-4385429.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/
>>>
>>> Mandy
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html 
>>>
>>
> 


From chris.hegarty at oracle.com  Mon Sep 17 10:16:08 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Sep 2018 11:16:08 +0100
Subject: RFR (12): 8210819: Update the host name in CNameTest.java
In-Reply-To: <047b01d44e55$c8758a40$59609ec0$@oracle.com>
References: <047b01d44e55$c8758a40$59609ec0$@oracle.com>
Message-ID: <3b159f75-2f25-616a-c9a9-e39145d420eb@oracle.com>

Looks fine Frank. Thanks,
-Chris.

On 17/09/18 08:12, Frank Yuan wrote:
> Hi
> 
>   
> 
> Would you like to review the following patch for
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210819
> 
>   
> 
> --- a/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java         Wed Sep 12 21:56:59 2018 -0700
> 
> +++ b/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java      Mon Sep 17 15:00:55 2018 +0800
> 
> @@ -1,5 +1,5 @@
> 
> /*
> 
> - * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
> 
> + * Copyright (c) 2017, 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
> 
> @@ -38,7 +38,7 @@
> 
>    * @summary Test DNS provider's handling of CNAME records
> 
>    */
> 
> public class CNameTest {
> 
> -    private static final String HOST = "www-proxy.us.oracle.com";
> 
> +    private static final String HOST = "www.w3c.org";
> 
>   
> 
> CNameTest.java is to test DNS provider's handling of CNAME records, so the test requires dns has cname record for the hostname. The
> old name is not appropriate, I would replace it with www.w3c.org <http://www.w3c.org> .
> 
>   
> 
> Thanks
> 
> Frank
> 

From christoph.langer at sap.com  Mon Sep 17 14:30:17 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 17 Sep 2018 14:30:17 +0000
Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip
 file is located in a custom file system
In-Reply-To: <5B9E00D8.8020505@oracle.com>
References: <5B9E00D8.8020505@oracle.com>
Message-ID: <4ed47defaea74d7a95f58e44e9c58fa1@sap.com>

Hi Sherman,

as I'm currently looking into zip stuff as well, it's a good exercise to review your changeset. Overall it looks good. I found a few nits mostly in the area of spelling and whitespace ??

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java:

88     ZipFileSystem(ZipFileSystemProvider provider,
I think, the constructor should initialize these items as last statements:
92         this.provider = provider;
93         this.zfpath = zfpath;
As per section 7-3 of the security guide which should probably apply here:
https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7

132     // returns ture if there is a name=true/"true" setting in env
-> spelling: // returns true if there is a name=true/"true" setting in env

282                                      // and sync dose not close the ch
-> spelling: // and sync did not close the ch

587     // (1) writing the contents of a new entry, if the entry doesn't exits, or
-> spelling: // (1) writing the contents of a new entry, if the entry doesn't exist, or

1471         }
1472         else {  // untouced  CEN or COPY
-> put brace and else on the same line to match style above and spelling of "untouched":          } else {  // untouched  CEN or COPY

remove these 2 lines that have been commented out:
1881         // Entry(byte[] name, boolean isdir) {
1889             //            this.method = METHOD_DEFLTED;

2402             fm.format("            name    : %s%n", new String(name));
2403             fm.format("    creationTime    : %tc%n", creationTime().toMillis());
-> I would align name with the start of creationTime (and the other lines below)



test/jdk/jdk/nio/zipfs/ZipFSTester.java:
134         try ( OutputStream os = Files.newOutputStream(src)) {
-> the blank between ( and OutputStream could be removed

436     private static void checkRead(Path path, byte[] expected) throws IOException
-> should take brace from line 437 on the same line, line length is not too long yet

438         //streams
-> insert a blank between // and streams

447        try (SeekableByteChannel sbc = Files.newByteChannel(path);
insert one more space before try to have correct indentation



src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java
43      * The currently position of this channel.
-> The current position of this channel.

97                 throw new IllegalArgumentException("negative position " + pos);
-> shouldn't it rather be "illegal position " as it must not necessarily be a negative position?

Assuming that the updated test case runs correctly, you can consider the changes reviewed from my end.

I'll post a change for adding executable bit support soon, based on your changes.

Best regards
Christoph

> -----Original Message-----
> From: nio-dev <nio-dev-bounces at openjdk.java.net> On Behalf Of Xueming
> Shen
> Sent: Sonntag, 16. September 2018 09:06
> To: core-libs-dev at openjdk.java.net; nio-dev <nio-dev at openjdk.java.net>
> Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip
> file is located in a custom file system
> 
> Hi
> 
> Please help review the change for JDK-8034802.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8034802
> webrev: http://cr.openjdk.java.net/~sherman/8034802/webrev
> 
> One of the reasons that the implementation works this way is that I
> didn't have a
> complete SeekableByteChannel support (mainly the position(...)) from
> newByteChannel()
> back then (so you really can't get a ZipFileSystem from a jar/zip file
> inside a zfs :-))
> 
> So this changeset also includes a ByteArrayChannel which implements SBC
> and has
> better position()/position(int) support, and now we can have a zipfs
> from a zip file
> inside a zipfs.
> 
> Thanks,
> Sherman
> 


From mandy.chung at oracle.com  Mon Sep 17 15:31:47 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 17 Sep 2018 08:31:47 -0700
Subject: <AWT Dev> [12] Review Request: 8210692 The
 "com.sun.awt.SecurityWarning" class can be dropped
In-Reply-To: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>
References: <a7779bd5-f6dc-e61f-f71b-9481117a88f4@oracle.com>
 <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com>
 <5B9D7300.8080207@oracle.com>
 <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com>
Message-ID: <933c7bc3-5ba3-bb63-2df8-20de1a877115@oracle.com>



On 9/16/18 12:48 AM, Alan Bateman wrote:
> On 15/09/2018 22:00, Philip Race wrote:
>> It was exported? in the past .. and it was publicly documented ..
>>
>> http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html 
>>
>>
>> .. so I think Sergey was correct in his "JDK" scope.
>> Implementation would be for something entirely internal.
> I think Sergey's changes are okay.
>
> The main issue with com.sun.awt API is that it tried to be both an 
> exported and internal/unsupported API at the same time (it's javadoc 
> reads "This class is an implementation detail and only meant for 
> limited use outside of the core platform"). This doesn't work for 
> modules. In addition the design principles in JEP 200 make it clear 
> that standard modules should not export a non-standard package to all 
> modules. If there has been extensive use of this API then I could 
> imagine it being refactored and moved into a JDK-specific module but 
> there was little evidence of usage. So where we ended up in JDK 9 is 
> that the API is not exported. This means, as Mandy hinted, you can't 
> compile against this API (at least not without --add-exports to the 
> compiler). Existing code using this API will continue to run on JDK 9, 
> 10, 11 or until the java.desktop module is fully encapsulated or the 
> SecurityWarning class is removed. Sergey got there first.
>

Yes.? Since it was decided not to export com.sun.awt API (JDK-8051640), 
they are no longer supported.? Is there a CSR filed officially declaring 
com.sun.awt APIs are no longer supported? Since it's already deprecated 
for removal, it may be worth to have a release note for JDK-8205588 if 
we didn't officially declare it unsupported.

Mandy

From sean.mullan at oracle.com  Mon Sep 17 15:37:21 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 17 Sep 2018 11:37:21 -0400
Subject: SSL session cache default maximum number of entries
In-Reply-To: <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com>
References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
 <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>
 <f46628d8-6f4e-ea03-99a9-cbcf456f7145@oracle.com>
 <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com>
Message-ID: <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com>

On 9/12/18 2:25 PM, Hohensee, Paul wrote:
> Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom.

Would you mind filing a bug and we will look into it?

Thanks,
Sean

> 
> Paul
> 
> ?On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.mullan at oracle.com> wrote:
> 
>      Hi Paul,
>      
>      Thank you for bringing this issue to our attention. While we agree that
>      this does indeed seem like an issue that should be addressed, it is
>      quite late in the JDK 11 schedule, and it does not appear to be a new
>      issue introduced in JDK 11. We will be investigating this offline and
>      will get back to you as soon as we can with more details. Offhand, I
>      think that we would be able to change the default in an update release.
>      
>      Also, you are probably already be aware of this, but you can use the
>      SSLSessionContext.setSessionCacheSize() API as well as the
>      "javax.net.ssl.sessionCacheSize" system property to customize the cache
>      size.
>      
>      --Sean
>      
>      On 9/11/18 12:02 PM, Sean Mullan wrote:
>      > cross-posting to security-dev since this is related to SSL/TLS.
>      >
>      > On 9/11/18 11:41 AM, Hohensee, Paul wrote:
>      >> The default value for the maximum number of entries in the SSL session
>      >> cache (which is a SoftReference cache) is infinite, and the entry
>      >> timeout is 24 hours. With larger heaps, we?re running into situations
>      >> where the cache ends up with several million entries when the 24 hours
>      >> are up. They?re then all invalidated at the same time, resulting in
>      >> multi-minute pauses (effectively service failures). We?ve experimented
>      >> with using 10k as the default maximum number of entries with good
>      >> results (i.e., no latency increases due to sessions falling out of the
>      >> cache). It?s late and a long shot for JDK11: we?d love to see it
>      >> changed there because 11 is an LTS release and this is, at least
>      >> nominally, a behavior change which might not be acceptable in 11u.
>      >> What do people think?
>      >>
>      >> Thanks,
>      >>
>      >> Paul
>      >>
>      
> 

From info at j-kuhn.de  Sun Sep 16 16:27:03 2018
From: info at j-kuhn.de (Johannes Kuhn)
Date: Sun, 16 Sep 2018 18:27:03 +0200
Subject: [JDK-8209078] Unable to call default interface methods from named
 module
In-Reply-To: <a92c5150-452f-c54c-21a1-71386f4d412b@oracle.com>
References: <5f272ab7-cd72-faaa-2705-d676671ab8e7@j-kuhn.de>
 <a92c5150-452f-c54c-21a1-71386f4d412b@oracle.com>
Message-ID: <75d48575-add8-4edf-1153-044b7b3cce05@j-kuhn.de>

Hi,

thanks for your quick reply.

On 16/09/2018 11:15, Alan Bateman wrote:
> On 14/09/2018 20:34, Johannes Kuhn wrote:
>> :
>>
>> 1. Use Case:
>>
>> The most obvious use case is to to "implement" default methods in
>> instances created by j.l.r.Proxy. An implementation of
>> j.l.r.InvocationHandler that handles default methods could look like
>> this:
>>
>> ???? public Object invoke(Object proxy, Method method, Object[] args)
>> ???????????? throws Throwable {
>> ???????? if (method.isDefault()) {
>> ???????????? MethodType mt = methodType(method.getReturnType(),
>> ???????????????????? method.getParameterTypes());
>> ???????????? Class<?> declaringClass = method.getDeclaringClass();
>> ???????????? Lookup l = MethodHandles.lookup();
>> ???????????? MethodHandle mh = l.findSpecial(declaringClass,
>> ???????????????????? method.getName(), mt, declaringClass)
>> ??????????????????? .asFixedArity()
>> ??????????????????? .bindTo(proxy);
>> ???????????? return mh.invokeWithArguments(args);
>> ???????? }
>> ???? // Handle the other methods
>> ???? return null;
>> ???? }
>>
>> Such a feature is very valuable so the InvocationHandler does not break
>> if an interface is evolved by adding new default methods.
> The common case will be a public interface in an exported package in
> which case the proxy will be generated in the unnamed module of the
> specified class loader. This means you can create a full-power lookup on
> the proxy class with:
> 
> Class<?> proxyClass = proxy.getClass();
> this.getClass().getModule().addReads(proxyClass.getModule());
> Lookup l = MethodHandles.privateLookupIn(proxyClass,
> MethodHandles.lookup());
> 
> If you invoke findSpecial on this lookup then I would expect it should
> work.

Thank you, this works fine. Unless you don't have
j.l.r.ReflectPermission("suppressAccessChecks").

I try to avoid requiring additional permissions if possible, and code in
an unnamed module does not need privateLookupIn.

Also j.l.r.ReflectPermission("suppressAccessChecks") is considered a
dangerous permission that allows a full sandbox escape.
> 
> There can be cases where the proxy is encapsulated (because the
> interfaces are not public or not in exported packages) but I assume you
> don't need to be concerned with those for now.
> 

Right, I am not concerned about that now.

>> :
>>
>>
>> 3. Cause of the discrepancy between lookup class in named module vs
>> unnamed module
>>
>> As Mandy Chung observed:
>>
>>> IAE is thrown because the implementation calls Lookup::in teleporting
>>> to a Lookup of the special class which lost all access since the
>>> caller class and the requested lookup class are in different modules.
>> This behavior is documented in the Lookup.in() [6]:
>>
>>> * If the old lookup class is in a named module, and the new lookup
>>> class is in a different module M, then no members, not even public
>>> members in M's exported packages, will be accessible. The exception to
>>> this is when this lookup is publicLookup, in which case PUBLIC access
>>> is not lost.
>>> * If the old lookup class is in an unnamed module, and the new lookup
>>> class is a different module then MODULE access is lost.
>> This strikes me as a little bit odd, so I looked around for the
>> reasoning for this difference, and found an old discussion on jigsaw-dev
>> [7]. I especially found this mail from Alan Bateman [8] interesting,
>> where he gave a reasoning for this:
>>
>>> Preserved but perhaps with the (initially surprising) consequence that
>>> all access is lost when m(LC) is a named module and m(A) is a
>>> different module. This arises because the two modules may read very
>>> different sets of modules, the intersection cannot be expressed via a
>>> lookup class + modes.
>> While I agree that intersection might not be expressed via lookup class
>> + modes, I don't think that it is necessary to express that. Instead
>> don't allow any lookup on members in a different module if the MODULE
>> flag is not set.
>>
> Qualified exports complicated this, as does readability. JDK-8173978 [1]
> tracks the need to support checking the intersection.
> 

I also had some thoughts about what semantics Lookup.in() can have.

A Lookup for class A can only be created in 3 ways:

* MethodHandles.lookup() called from A - full access
* MethodHandles.privateLookupIn() - full access
* Lookup.in() - drops modes depending on the distance.

The reasoning for Lookup.in() should always be:

** If a mode bit is set, then the original lookup is the same class or
in the same nest/package/module (depending on the corresponding mode
bit). **

Note that the opposite is not required to be true.

This enforces that if the MODULE bit is set, we know the original module.

If we need to know the original class/nest/package/module to perform a
check but the corresponding mode bit is not set, then we can not know
the original class/nest/package/module, and we have to drop all modes.

Therefore modes should be dropped when teleporting from class A to B
(L.in(B), where L.lookupClass() == A) in this order:

a) If A and B are the same, no modes are dropped, otherwise PROTECTED is
always dropped.
b) If A and B are in the same nest and L has private access, no further
modes are dropped, otherwise PRIVATE is dropped.
c) If A and B are in the same (runtime) package and L has package
access, no further modes are dropped, otherwise PACKAGE is dropped.
d) If B is not public, all modes are dropped.
e) If A and B are in the same module and L has module access, then no
further modes are dropped, otherwise MODULE will be dropped.
f) If A and B are in the same module, L has PUBLIC access and B's
package is the same as A or unconditionally exported, then no further
modes are dropped.
g) If If L has module access (old modes) and
B.getModule().isExported(B.getPackageName(), A.getModule()) then no
further modes are dropped, otherwise all modes are dropped.

Notes:
* f) uses PUBLIC access for the same module. This is safe because module
access and package access was already checked when L was created.
* g) makes use of the fact, that if the MODULE bit is set, we know the
module of the original lookup.
* There is no difference between named and unnamed modules.

But maybe I'm missing some pieces here.


> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8173978
>
>
>

Thank you for this pointer, maybe I should rename this thread then?

-Johannes

From xueming.shen at oracle.com  Mon Sep 17 17:51:05 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 17 Sep 2018 10:51:05 -0700
Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip
 file is located in a custom file system
In-Reply-To: <4ed47defaea74d7a95f58e44e9c58fa1@sap.com>
References: <5B9E00D8.8020505@oracle.com>
 <4ed47defaea74d7a95f58e44e9c58fa1@sap.com>
Message-ID: <5B9FE989.20509@oracle.com>

Thanks!

webrev has been updated accordingly.

http://cr.openjdk.java.net/~sherman/8034802/webrev/

-Sherman

On 09/17/2018 07:30 AM, Langer, Christoph wrote:
> Hi Sherman,
>
> as I'm currently looking into zip stuff as well, it's a good exercise to review your changeset. Overall it looks good. I found a few nits mostly in the area of spelling and whitespace ??
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java:
>
> 88     ZipFileSystem(ZipFileSystemProvider provider,
> I think, the constructor should initialize these items as last statements:
> 92         this.provider = provider;
> 93         this.zfpath = zfpath;
> As per section 7-3 of the security guide which should probably apply here:
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7
>
> 132     // returns ture if there is a name=true/"true" setting in env
> ->  spelling: // returns true if there is a name=true/"true" setting in env
>
> 282                                      // and sync dose not close the ch
> ->  spelling: // and sync did not close the ch
>
> 587     // (1) writing the contents of a new entry, if the entry doesn't exits, or
> ->  spelling: // (1) writing the contents of a new entry, if the entry doesn't exist, or
>
> 1471         }
> 1472         else {  // untouced  CEN or COPY
> ->  put brace and else on the same line to match style above and spelling of "untouched":          } else {  // untouched  CEN or COPY
>
> remove these 2 lines that have been commented out:
> 1881         // Entry(byte[] name, boolean isdir) {
> 1889             //            this.method = METHOD_DEFLTED;
>
> 2402             fm.format("            name    : %s%n", new String(name));
> 2403             fm.format("    creationTime    : %tc%n", creationTime().toMillis());
> ->  I would align name with the start of creationTime (and the other lines below)
>
>
>
> test/jdk/jdk/nio/zipfs/ZipFSTester.java:
> 134         try ( OutputStream os = Files.newOutputStream(src)) {
> ->  the blank between ( and OutputStream could be removed
>
> 436     private static void checkRead(Path path, byte[] expected) throws IOException
> ->  should take brace from line 437 on the same line, line length is not too long yet
>
> 438         //streams
> ->  insert a blank between // and streams
>
> 447        try (SeekableByteChannel sbc = Files.newByteChannel(path);
> insert one more space before try to have correct indentation
>
>
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java
> 43      * The currently position of this channel.
> ->  The current position of this channel.
>
> 97                 throw new IllegalArgumentException("negative position " + pos);
> ->  shouldn't it rather be "illegal position " as it must not necessarily be a negative position?
>
> Assuming that the updated test case runs correctly, you can consider the changes reviewed from my end.
>
> I'll post a change for adding executable bit support soon, based on your changes.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: nio-dev<nio-dev-bounces at openjdk.java.net>  On Behalf Of Xueming
>> Shen
>> Sent: Sonntag, 16. September 2018 09:06
>> To: core-libs-dev at openjdk.java.net; nio-dev<nio-dev at openjdk.java.net>
>> Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip
>> file is located in a custom file system
>>
>> Hi
>>
>> Please help review the change for JDK-8034802.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8034802
>> webrev: http://cr.openjdk.java.net/~sherman/8034802/webrev
>>
>> One of the reasons that the implementation works this way is that I
>> didn't have a
>> complete SeekableByteChannel support (mainly the position(...)) from
>> newByteChannel()
>> back then (so you really can't get a ZipFileSystem from a jar/zip file
>> inside a zfs :-))
>>
>> So this changeset also includes a ByteArrayChannel which implements SBC
>> and has
>> better position()/position(int) support, and now we can have a zipfs
>> from a zip file
>> inside a zipfs.
>>
>> Thanks,
>> Sherman
>>


From huizhe.wang at oracle.com  Mon Sep 17 18:44:26 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 17 Sep 2018 11:44:26 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <a3e04203-bce0-a8b0-539a-6034831aec94@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
 <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
 <5B9BEB24.5040605@oracle.com>
 <a3e04203-bce0-a8b0-539a-6034831aec94@oracle.com>
Message-ID: <5B9FF60A.2040004@oracle.com>

Yikes, right, the process must avoid advancing the index if the pair is 
written when the current char is low surrogate.

webrev02:
http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev02/

Thanks,
Joe

On 9/17/18, 3:10 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> hmmm... I'm not sure I'm completely convinced.
>
> Let's take an example, and assume your input
> has been split in two strings of 4 characters each
> (the code I'm seeing implies that this is possible,
> right?) In the sketch below the first line represents
> the loop iterations, the second line represents
> the two strings as char buffers (hs = high surrogate,
> ls = low surrogate, x,y = just regular chars), the third
> line represents index increments, and the fourth line
> represents the result of the writeUTF16Surrogate method:
>
> L1:   1   -  2    3        1      2    3   -
> L2: [ hs  ls x    hs ]   [ ls     y    hs  ls ]
> L3:   \i+2/  i++  i++      i++    i++  \i+2/
> L4:   cp||0       -1       cp||-1      cp||0
>
> We have two calls to writeAttrString, the first
> call writes the first 4 chars string, the second
> write the next 4 chars.
>
> In the sketch above, i++ indicates a regular
> increment from the loop, and i+2 indicates
> where i++ must be called a second time within
> the loop because two characters were consumed
> in a single iteration.
>
> So it seems to me that the only time you want to
> increment the index a second time is when you read
> (and wrote) both surrogate in one shot.
>
> In the pathological case - where the surrogate pair
> was split at the string limit, there will be two
> calls to writeUTF16Surrogate(...). One with the
> high surrogate, that will return -1, and one with
> the low surrogate that will either return -1 or a
> code point. And in that case you don't want to
> increment i a second time - or the character
> 'y' will be skipped.
>
> Am I still missing something?
>
> best regards,
>
> -- daniel
>
>
> On 14/09/2018 18:08, Joe Wang wrote:
>> Hi Daniel,
>>
>> The additional advance is made when the pair has already been 
>> written, which is indicated by the return value of 
>> writeUTF16Surrogate being >= 0*. Encodings.isHighUTF16Surrogate(ch) 
>> therefore would be redundant.
>>
>> * Note that the return value is: -1 when nothing is written, 0 when 
>> the pair is written, so the condition of >= 0 means no matter there 
>> is a codepoint value or not, the index increment as long as the pair 
>> is written (the low surrogate is consumed).
>>
>> Best,
>> Joe
>>
>> On 9/14/18, 3:00 AM, Daniel Fuchs wrote:
>>> Hi Joe,
>>>
>>> Thanks for doing that - it's a far better solution.
>>>
>>> ToHTMLStream.java:
>>>
>>> 1432    // move the index if the surrogate pair has been written.
>>> 1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
>>> 1434        i++;
>>> 1435    }
>>>
>>> shouldn't this be:
>>>
>>> 1433    if (writeUTF16Surrogate(ch, chars, i, end) >= 0) {
>>>             if (Encodings.isHighUTF16Surrogate(ch)) {
>>>                 // two input characters processed, increase
>>>                 // the index again.
>>>                 i++;
>>>             }
>>>
>>> IIUC you only want to increase the index if the ch was the
>>> high surrogate and the function has advanced to the low
>>> surrogate?
>>>
>>> I mean - a codepoint could have been returned if ch was the
>>> low surrogate, and in that case you don't want to increase
>>> the index twice as only one character has been consumed.
>>>
>>> I guess there's the same issue in ToStream.java at lines
>>> 1154-1156 and in ToTextStream.java at line 303...
>>>
>>> Or am I missing something?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>> On 14/09/2018 04:13, Joe Wang wrote:
>>>> Thanks Daniel.
>>>>
>>>> I changed the return of writeUTF16Surrogate so that it is clearer 
>>>> within writeUTF16Surrogate when an additional index increment is 
>>>> needed. Other corresponding changes are in ToHTMLStream and 
>>>> ToTextStream where similar calls to the method are made. It's been 
>>>> an issue in some part of JAXP impl where error or warning messages 
>>>> are printed out to the console (e.g. JDK-8000621). But I kept it as 
>>>> is in ToTextStream for this patch.
>>>>
>>>> webrev01:
>>>> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev01/
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>> On 9/13/18, 2:23 AM, Daniel Fuchs wrote:
>>>>> Hi Joe,
>>>>>
>>>>> On 13/09/2018 00:25, Lance Andersen wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> The change  seems reasonable
>>>>>
>>>>> Agreed. However the following condition in ToStream::handleEscaping
>>>>> is a bit cryptic:
>>>>>
>>>>> 1155             if ((ihs && (i + 1 < end)) || (ils && i != 0)) {
>>>>> 1156                 i++ ; // process two input characters
>>>>> 1157             }
>>>>>
>>>>> could the comment be fleshed out to explain it?
>>>>>
>>>>> I suspect that: `(ihs && (i + 1 < end))` means that
>>>>> `writeUTF16Surrogate(c, ch, i, end);` has written the two 
>>>>> surrogate, in
>>>>> which case i should be incremented in order to skip the low surrogate
>>>>> which has just been written.
>>>>>
>>>>> I am not sure what `(ils && i != 0)` means, though...
>>>>>
>>>>> best regards
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>>> On Sep 12, 2018, at 2:11 PM, Joe Wang <huizhe.wang at oracle.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review a patch for a situation where a surrogate pair is 
>>>>>>> at the edge of a buffer. What the existing impl did was to 
>>>>>>> report it as an error. This patch fixes it by caching the high 
>>>>>>> surrogate and prints it out along with the low surrogate. 
>>>>>>> Similar issue exists also in the CDATA section and is fixed in 
>>>>>>> this patch. The CDATA impl had a couple of bugs where an indent 
>>>>>>> could be written inside the CDATA and an unicode character 
>>>>>>> written in between two CDATA sections. Both are fixed in this 
>>>>>>> patch.
>>>>>>>
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207760
>>>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev/
>>>>>>>
>>>>>>> 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 daniel.fuchs at oracle.com  Mon Sep 17 20:43:09 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Sep 2018 21:43:09 +0100
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <5B9FF60A.2040004@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
 <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
 <5B9BEB24.5040605@oracle.com>
 <a3e04203-bce0-a8b0-539a-6034831aec94@oracle.com>
 <5B9FF60A.2040004@oracle.com>
Message-ID: <9315f10a-8b33-e0f9-75d3-f5e0cb7cc10c@oracle.com>

Hi Joe,

Looks right to me now.

Cheers,

-- daniel

On 17/09/18 19:44, Joe Wang wrote:
> Yikes, right, the process must avoid advancing the index if the pair is 
> written when the current char is low surrogate.
> 
> webrev02:
> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev02/
> 
> Thanks,
> Joe

From huizhe.wang at oracle.com  Mon Sep 17 21:04:03 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 17 Sep 2018 14:04:03 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8207760: SAXException: Invalid UTF-16
 surrogate detected: d83c ?
In-Reply-To: <9315f10a-8b33-e0f9-75d3-f5e0cb7cc10c@oracle.com>
References: <5B9956B9.104@oracle.com>
 <7DD4A7E7-25CF-4BA4-9A15-48EC76A8AA20@oracle.com>
 <ecd64239-0192-e402-49b1-a02918584ab2@oracle.com>
 <5B9B276C.2010609@oracle.com>
 <3e4818f8-cf6c-c6ad-557e-d8a1ac19c7ed@oracle.com>
 <5B9BEB24.5040605@oracle.com>
 <a3e04203-bce0-a8b0-539a-6034831aec94@oracle.com>
 <5B9FF60A.2040004@oracle.com>
 <9315f10a-8b33-e0f9-75d3-f5e0cb7cc10c@oracle.com>
Message-ID: <5BA016C3.4040407@oracle.com>

Thanks Daniel!  Will run tests again before checking in.

-Joe

On 9/17/18, 1:43 PM, Daniel Fuchs wrote:
> Hi Joe,
>
> Looks right to me now.
>
> Cheers,
>
> -- daniel
>
> On 17/09/18 19:44, Joe Wang wrote:
>> Yikes, right, the process must avoid advancing the index if the pair 
>> is written when the current char is low surrogate.
>>
>> webrev02:
>> http://cr.openjdk.java.net/~joehw/jdk12/8207760/webrev02/
>>
>> Thanks,
>> Joe

From forax at univ-mlv.fr  Mon Sep 17 22:28:29 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 18 Sep 2018 00:28:29 +0200 (CEST)
Subject: Thought on multiplicity of properties in Java
In-Reply-To: <ec6ef0ad-0027-0176-3e83-3b01b9a2b7b5@geomatys.com>
References: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>
 <1876540140.5154.1537138499879.JavaMail.zimbra@u-pem.fr>
 <ec6ef0ad-0027-0176-3e83-3b01b9a2b7b5@geomatys.com>
Message-ID: <1172333748.153703.1537223309826.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Martin Desruisseaux" <martin.desruisseaux at geomatys.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 17 Septembre 2018 10:21:50
> Objet: Re: Thought on multiplicity of properties in Java

> Hello R?mi

Hi Martin,

> 
> Thanks for your reply.
> 
> Le 17/09/2018 ? 00:54, Remi Forax a ?crit?:
> 
>> The Java spec limit covariance to subtyping relationship only (there
>> is no covariance between primitive types, or between a primitive type
>> and it's corresponding wrapper), so you can not use Java to implement
>> overriding of UML properties with different multiplicity. But if you
>> generate the bytecode instead of generating Java code to generate the
>> interfaces, you are not limited by the Java spec, so you can generate
>> the bridge methods you want.
>>
> Yes I know. My question was if "multiplicity covariance" was something
> that may be worth considering at the Java language level for some future
> version of the specification. This is not a request to do so, only an idea.

I don't think it's a good idea. i see three flaws:
- theoretically, the covariance is defined in term of sub-typing, trying to widen it's definition may have unintended consequences that need studying.
- technically, we can implement whatever conversions we want because the "convariance conversion" is implemented using brige, but we may not implement that the "covariance conversion" using bridges in the future if by example we do some kind of reification of the type arguments, so this may hamper the possible futures of Java.
- the conversion from Optional to a List is not a conversion already defined by the JLS, this need also to be specified because there is no reason to limit this conversion to only the covariance case, by example if you have an Optional<String> named opt, this statement List<String> list = opt; should compile. This means that you have to formally defines the conversion and perhaps the reverse conversion too, Optional<String> opt2 = (Optional<String>)list; at that point you are not backward compatible with the current JLS because this code currently always throws a CCE.


> 
>??? Regards,
> 
> ??? ??? Martin

regards,
R?mi

From martinrb at google.com  Tue Sep 18 01:24:24 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 17 Sep 2018 18:24:24 -0700
Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use
 FD_CLOEXEC instead of close()
In-Reply-To: <CA+kOe0_wbxUxvLp3Tmg-u8B4v3AFE4pRVkcnDYVMqxWaizVt_Q@mail.gmail.com>
References: <CAA-vtUyxGULcikf3ev+7UWPK2RfztXxikXaDGfNdmW0OiyQOZQ@mail.gmail.com>
 <CA+kOe0_wbxUxvLp3Tmg-u8B4v3AFE4pRVkcnDYVMqxWaizVt_Q@mail.gmail.com>
Message-ID: <CA+kOe098yF8GK_Jyh2VHCEG=EDzry-Dq54iEPhFEs6RbV1W=bg@mail.gmail.com>

More concurrent discussion over in libc-alpha
"""system and popen fail in case of big application"""
http://sourceware-org.1504.n7.nabble.com/system-and-popen-fail-in-case-of-big-application-tt534908.html#a537069

On Wed, Sep 12, 2018 at 6:17 AM, Martin Buchholz <martinrb at google.com> wrote:
> In 2018, we can assume everyone has implemented FD_CLOEXEC.
>
> Back in 1970, 20 file descriptors was enough for any program, but
> today they're effectively unlimited, so futilely closing _SC_OPEN_MAX
> descriptors has become unreasonable (as you say).  OTOH, there is
> still no standard way of ensuring all our file descriptors are closed.
> Do we need the fallback on your beloved HP-UX?  Should we simply close
> the first 64k file descriptors and pray, as is traditional?
>
> freebsd offers closefrom(2)
> https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpath=freebsd-release-ports
> and today we can autoconfiscate the existence of closefrom and use
> that where available (BSD and Solaris?)
>
> closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ?
>
> I'd give this function a javadoc style docstring.
>
> (Finding the FD_DIR directory has become rather ugly, especially the
> AIX-specific code)

From frank.yuan at oracle.com  Tue Sep 18 03:12:32 2018
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 18 Sep 2018 11:12:32 +0800
Subject: RFR (12): 8210819: Update the host name in CNameTest.java
In-Reply-To: <3b159f75-2f25-616a-c9a9-e39145d420eb@oracle.com>
References: <047b01d44e55$c8758a40$59609ec0$@oracle.com>
 <3b159f75-2f25-616a-c9a9-e39145d420eb@oracle.com>
Message-ID: <069401d44efd$725e6bb0$571b4310$@oracle.com>

Thank you! Pushed.

Frank

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Monday, September 17, 2018 6:16 PM
> To: Frank Yuan; 'core-libs-dev'
> Subject: Re: RFR (12): 8210819: Update the host name in CNameTest.java
> 
> Looks fine Frank. Thanks,
> -Chris.
> 
> On 17/09/18 08:12, Frank Yuan wrote:
> > Hi
> >
> >
> >
> > Would you like to review the following patch for
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210819
> >
> >
> >
> > --- a/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java         Wed Sep 12 21:56:59 2018 -0700
> >
> > +++ b/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java      Mon Sep 17 15:00:55 2018 +0800
> >
> > @@ -1,5 +1,5 @@
> >
> > /*
> >
> > - * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
> >
> > + * Copyright (c) 2017, 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
> >
> > @@ -38,7 +38,7 @@
> >
> >    * @summary Test DNS provider's handling of CNAME records
> >
> >    */
> >
> > public class CNameTest {
> >
> > -    private static final String HOST = "www-proxy.us.oracle.com";
> >
> > +    private static final String HOST = "www.w3c.org";
> >
> >
> >
> > CNameTest.java is to test DNS provider's handling of CNAME records, so the test requires dns has cname record for the hostname. The
> > old name is not appropriate, I would replace it with www.w3c.org <http://www.w3c.org> .
> >
> >
> >
> > Thanks
> >
> > Frank
> >


From mandy.chung at oracle.com  Tue Sep 18 05:12:15 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 17 Sep 2018 22:12:15 -0700
Subject: Review Request JDK-8210841:
 test/jdk/vm/runtime/ReflectStackOverflow.java fails with NoClassDefFoundError
Message-ID: <5ffd697b-c205-bd62-9c02-e493b9dae00a@oracle.com>

test/jdk/vm/runtime/ReflectStackOverflow.java fails and it's caused by
JDK-8210721.? I propose to revert the change in InvocationTargetException
to give us time to investigate this regression.

webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210841/webrev.00/

thanks
Mandy



From mikael.vidstedt at oracle.com  Tue Sep 18 05:32:24 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 17 Sep 2018 22:32:24 -0700
Subject: Review Request JDK-8210841:
 test/jdk/vm/runtime/ReflectStackOverflow.java fails with NoClassDefFoundError
In-Reply-To: <5ffd697b-c205-bd62-9c02-e493b9dae00a@oracle.com>
References: <5ffd697b-c205-bd62-9c02-e493b9dae00a@oracle.com>
Message-ID: <52B1643D-BC8C-4B38-BF3C-C19F3009015E@oracle.com>


Looks like a clean reverse of that file.

Cheers,
Mikael - not a Reviewer

> On Sep 17, 2018, at 10:12 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> test/jdk/vm/runtime/ReflectStackOverflow.java fails and it's caused by
> JDK-8210721.  I propose to revert the change in InvocationTargetException
> to give us time to investigate this regression.
> 
> webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210841/webrev.00/
> 
> thanks
> Mandy
> 
> 


From david.holmes at oracle.com  Tue Sep 18 05:34:09 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Sep 2018 15:34:09 +1000
Subject: Review Request JDK-8210841:
 test/jdk/vm/runtime/ReflectStackOverflow.java fails with NoClassDefFoundError
In-Reply-To: <52B1643D-BC8C-4B38-BF3C-C19F3009015E@oracle.com>
References: <5ffd697b-c205-bd62-9c02-e493b9dae00a@oracle.com>
 <52B1643D-BC8C-4B38-BF3C-C19F3009015E@oracle.com>
Message-ID: <fbc3a869-24cd-f4eb-776e-fc99d3efd3e4@oracle.com>

+1 Reviewed.

Thanks,
David

On 18/09/2018 3:32 PM, Mikael Vidstedt wrote:
> 
> Looks like a clean reverse of that file.
> 
> Cheers,
> Mikael - not a Reviewer
> 
>> On Sep 17, 2018, at 10:12 PM, mandy chung <mandy.chung at oracle.com> wrote:
>>
>> test/jdk/vm/runtime/ReflectStackOverflow.java fails and it's caused by
>> JDK-8210721.  I propose to revert the change in InvocationTargetException
>> to give us time to investigate this regression.
>>
>> webrev:
>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210841/webrev.00/
>>
>> thanks
>> Mandy
>>
>>
> 

From martin.desruisseaux at geomatys.com  Tue Sep 18 08:16:27 2018
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Tue, 18 Sep 2018 10:16:27 +0200
Subject: Thought on multiplicity of properties in Java
In-Reply-To: <1172333748.153703.1537223309826.JavaMail.zimbra@u-pem.fr>
References: <958d3486-34de-541a-a07b-ac21a754be96@geomatys.com>
 <1876540140.5154.1537138499879.JavaMail.zimbra@u-pem.fr>
 <ec6ef0ad-0027-0176-3e83-3b01b9a2b7b5@geomatys.com>
 <1172333748.153703.1537223309826.JavaMail.zimbra@u-pem.fr>
Message-ID: <c954bc1e-536c-4924-dbae-57a4a7338dde@geomatys.com>

Hello R?mi

Le 18/09/2018 ? 00:28, forax at univ-mlv.fr a ?crit?:

> - theoretically, the covariance is defined in term of sub-typing,
> trying to widen it's definition may have unintended consequences that
> need studying.
>
Agree that it would require studying. But we have a general guidance,
which is that a subtype must obey to all constraints declared in the
parent type. The Java type covariance follow that rule: we can use a
more specific return type in a subclass, but not the converse since it
would broke the constraint defined by the return type in the parent
class. The proposed "multiplicity covariance" follows the same rule: a
subclass would be allowed to define a more specific multiplicity, but
the converse is not allowed. For example a [0?1] multiplicity defined in
the parent class can be restricted to the [1?1] multiplicity in a
subclass, but can not be changed to [0?2] or any other value outside the
[0?1] range.


> - technically, we can implement whatever conversions we want because
> the "convariance conversion" is implemented using brige, but we may
> not implement that the "covariance conversion" using bridges in the
> future if by example we do some kind of reification of the type
> arguments, so this may hamper the possible futures of Java.
>
The proposed "multiplicity covariance conversion" would be implemented
using bridges too. However I admit that I lack knowledge on the
consequences in a context of reification.


> - the conversion from Optional to a List is not a conversion already
> defined by the JLS, this need also to be specified because there is no
> reason to limit this conversion to only the covariance case, by
> example if you have an Optional<String> named opt, this statement
> List<String> list = opt; should compile. This means that you have to
> formally defines the conversion and perhaps the reverse conversion
> too, Optional<String> opt2 = (Optional<String>)list; at that point you
> are not backward compatible with the current JLS because this code
> currently always throws a CCE.
>
In the "multiplicity covariance" proposal, the set of conversions that
are allowed is determined by the above-cited rule that multiplicity in
return value can only be restricted - not widened. By labelling Foo =
[1?1], Optional<Foo> = [0?1] and Collection<Foo> = [0??], we can build
the set of allowed conversions. Those conversions would not be performed
by casts, but by bridge methods (in widening direction because the
bridge methods implement the methods defined by parent class):

  * [0?1] ? [1?1]: Optional.of(value);
  * [0??] ? [1?1]: List.of(value);
  * [0??] ? [0?1]: if empty Collections.emptyList() otherwise
    List.of(value);

Martin



From leventov.ru at gmail.com  Tue Sep 18 09:38:13 2018
From: leventov.ru at gmail.com (Roman Leventov)
Date: Tue, 18 Sep 2018 13:38:13 +0400
Subject: Sized Collector supplier
Message-ID: <CAAMLo=bCSNYM95xvSMj4wRhVLS5YOtkHr-gAjZ2Sa2+vWj_9jw@mail.gmail.com>

Is there a reason why java.util.stream.Collector doesn't support sized
supply of a mutable result container? It seems that it could be hugely
beneficial when the size of the stream is known, e. g. for precise
ArrayList and HashMap.

From james at lightbend.com  Tue Sep 18 12:19:54 2018
From: james at lightbend.com (James Roper)
Date: Tue, 18 Sep 2018 22:19:54 +1000
Subject: Reactive Streams utility API
In-Reply-To: <03157EE0-B511-4733-B44E-82B838952DE0@oracle.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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
Message-ID: <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>

Hi Pavel,

Thanks for asking about this. I was meant to send an update to the list
earlier but never got around to it.

As you probably noticed from the history of this thread, there was a
deafening silence in response to it. We decided that core-libs-dev might
not have been the best place to start this effort. So we've taken it to
Eclipse MicroProfile, and the intention is to incubate it there, and then
once we have something that we're reasonably happy with, look at
contributing that to the JDK. That strategy has so far gone really well.
The project lives here:

https://github.com/eclipse/microprofile-reactive-streams

We have a specification:

http://download.eclipse.org/microprofile/microprofile-reactive-1.0-M1/microprofile-reactive-streams-operators-spec.html

A TCK (see the TCK section of the spec for info).

Comprehensive API docs:

http://download.eclipse.org/microprofile/microprofile-reactive-1.0-M1/apidocs/

And all this has been produced by a team of around 10 contributors from
five different companies (Lightbend, RedHat, IBM, Payara and Tomitribe),
with all meetings recorded and minuted:

https://docs.google.com/document/d/1UKBBNFn-CeMih3lNUGvpShcL2aTpnvmJs9LQ8qT9OI0/edit#

We are about to release a 1.0-RC1, and are planning to have a 1.0 out in
time for Oracle Code One, where there will be some presentations on it.

My plan was, once 1.0 was released, to resume discussions on this list
about whether this could be contributed to the JDK, possibly as an
incubating module.

Are there any questions in particular that you have about it? If you're
interested, we have an open meeting every Tuesday, 1100 UTC, that you're
welcome to join (actually next week we're expecting some other Oracle devs
to join from the team that produced Helidon). A link to the calendar event
for this meeting, with links to the Zoom meeting and minutes, can be found
here:

https://calendar.google.com/calendar/event?eid=NDk3ZjQxMjkyZGh1N2lrZnU2dTk0Y29laWtfMjAxODA5MjVUMTEwMDAwWiBnYm5iYzM3M2dhNDBuMHR2Ymw4OG5rYzNyNEBn&ctz=Etc/GMT

Cheers,

James

On Tue, 28 Aug 2018 at 00:33, Pavel Rappo <pavel.rappo at oracle.com> wrote:

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

-- 
*James Roper*
*Senior Developer, Office of the CTO*

Lightbend <https://www.lightbend.com/> ? Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>

From amaembo at gmail.com  Tue Sep 18 15:19:47 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 18 Sep 2018 22:19:47 +0700
Subject: Sized Collector supplier
In-Reply-To: <CAAMLo=bCSNYM95xvSMj4wRhVLS5YOtkHr-gAjZ2Sa2+vWj_9jw@mail.gmail.com>
References: <CAAMLo=bCSNYM95xvSMj4wRhVLS5YOtkHr-gAjZ2Sa2+vWj_9jw@mail.gmail.com>
Message-ID: <CAE+3fjZ7QzVit-Xw1e_APYciPze-6YCvC6mm85H4aYvxMn99Nw@mail.gmail.com>

 Hello!

See the ticket:
https://bugs.openjdk.java.net/browse/JDK-8072840

In my opinion only toList and toUnmodifiableList collectors would benefit
significantly, but this could be solved in alternative way, adding the
corresponding methods to the stream interface. Another possibility is to
add a hidden API for this case (e. g. add new method to CollectorImpl and
branch on `instanceof CollectorImpl` inside ReferencePipeline.collect`).
This would add a performance benefit for JDK collectors and JDK stream
implementation without exposing new API. If somebody interested, I can
implement this. In general I don't think that improvement of a couple of
collectors performance justifies increasing public API complexity.

To my opinion Collectors would benefit much more if they support
short-circuiting. There are much more interesting use-cases which could be
covered with short-circuiting collectors.

With best regards,
Tagir Valeev.



??, 18 ????. 2018 ?., 16:39 Roman Leventov <leventov.ru at gmail.com>:

> Is there a reason why java.util.stream.Collector doesn't support sized
> supply of a mutable result container? It seems that it could be hugely
> beneficial when the size of the stream is known, e. g. for precise
> ArrayList and HashMap.
>

From fenix_young at hotmail.com  Tue Sep 18 03:42:40 2018
From: fenix_young at hotmail.com (Young xiaofeng)
Date: Tue, 18 Sep 2018 03:42:40 +0000
Subject: =?utf-8?B?562U5aSNOiBSRlIgSkRLLTgwMzQ4MDI6ICh6aXBmcykgbmV3RmlsZVN5c3Rl?=
 =?utf-8?B?bSB0aHJvd3MgVU9FIHdoZW4gdGhlIHppcCBmaWxlIGlzIGxvY2F0ZWQgaW4g?=
 =?utf-8?Q?a_custom_file_system?=
In-Reply-To: <5B9FE989.20509@oracle.com>
References: <5B9E00D8.8020505@oracle.com>
 <4ed47defaea74d7a95f58e44e9c58fa1@sap.com>,<5B9FE989.20509@oracle.com>
Message-ID: <DM5PR13MB1626AE39A8466F3C35F25C66861D0@DM5PR13MB1626.namprd13.prod.outlook.com>

Hi Sherman,

     just one comment, the copyright dates in ZipFileSystem.java, ZipFileSystemProvider.java and ZipFSTester.java are not updated.


-Felix

________________________________
???: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> ?? Xueming Shen <xueming.shen at oracle.com>
????: 2018?9?17? 17:51:05
???: Langer, Christoph
??: nio-dev; core-libs-dev at openjdk.java.net
??: Re: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip file is located in a custom file system

Thanks!

webrev has been updated accordingly.

http://cr.openjdk.java.net/~sherman/8034802/webrev/

-Sherman

On 09/17/2018 07:30 AM, Langer, Christoph wrote:
> Hi Sherman,
>
> as I'm currently looking into zip stuff as well, it's a good exercise to review your changeset. Overall it looks good. I found a few nits mostly in the area of spelling and whitespace ??
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java:
>
> 88     ZipFileSystem(ZipFileSystemProvider provider,
> I think, the constructor should initialize these items as last statements:
> 92         this.provider = provider;
> 93         this.zfpath = zfpath;
> As per section 7-3 of the security guide which should probably apply here:
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#7
>
> 132     // returns ture if there is a name=true/"true" setting in env
> ->  spelling: // returns true if there is a name=true/"true" setting in env
>
> 282                                      // and sync dose not close the ch
> ->  spelling: // and sync did not close the ch
>
> 587     // (1) writing the contents of a new entry, if the entry doesn't exits, or
> ->  spelling: // (1) writing the contents of a new entry, if the entry doesn't exist, or
>
> 1471         }
> 1472         else {  // untouced  CEN or COPY
> ->  put brace and else on the same line to match style above and spelling of "untouched":          } else {  // untouched  CEN or COPY
>
> remove these 2 lines that have been commented out:
> 1881         // Entry(byte[] name, boolean isdir) {
> 1889             //            this.method = METHOD_DEFLTED;
>
> 2402             fm.format("            name    : %s%n", new String(name));
> 2403             fm.format("    creationTime    : %tc%n", creationTime().toMillis());
> ->  I would align name with the start of creationTime (and the other lines below)
>
>
>
> test/jdk/jdk/nio/zipfs/ZipFSTester.java:
> 134         try ( OutputStream os = Files.newOutputStream(src)) {
> ->  the blank between ( and OutputStream could be removed
>
> 436     private static void checkRead(Path path, byte[] expected) throws IOException
> ->  should take brace from line 437 on the same line, line length is not too long yet
>
> 438         //streams
> ->  insert a blank between // and streams
>
> 447        try (SeekableByteChannel sbc = Files.newByteChannel(path);
> insert one more space before try to have correct indentation
>
>
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java
> 43      * The currently position of this channel.
> ->  The current position of this channel.
>
> 97                 throw new IllegalArgumentException("negative position " + pos);
> ->  shouldn't it rather be "illegal position " as it must not necessarily be a negative position?
>
> Assuming that the updated test case runs correctly, you can consider the changes reviewed from my end.
>
> I'll post a change for adding executable bit support soon, based on your changes.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: nio-dev<nio-dev-bounces at openjdk.java.net>  On Behalf Of Xueming
>> Shen
>> Sent: Sonntag, 16. September 2018 09:06
>> To: core-libs-dev at openjdk.java.net; nio-dev<nio-dev at openjdk.java.net>
>> Subject: RFR JDK-8034802: (zipfs) newFileSystem throws UOE when the zip
>> file is located in a custom file system
>>
>> Hi
>>
>> Please help review the change for JDK-8034802.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8034802
>> webrev: http://cr.openjdk.java.net/~sherman/8034802/webrev
>>
>> One of the reasons that the implementation works this way is that I
>> didn't have a
>> complete SeekableByteChannel support (mainly the position(...)) from
>> newByteChannel()
>> back then (so you really can't get a ZipFileSystem from a jar/zip file
>> inside a zfs :-))
>>
>> So this changeset also includes a ByteArrayChannel which implements SBC
>> and has
>> better position()/position(int) support, and now we can have a zipfs
>> from a zip file
>> inside a zipfs.
>>
>> Thanks,
>> Sherman
>>


From brent.christian at oracle.com  Tue Sep 18 16:42:07 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 18 Sep 2018 09:42:07 -0700
Subject: RFR 12 : 8072130 :
 java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
In-Reply-To: <f708030e-d825-d016-2b8b-763f71403739@oracle.com>
References: <f708030e-d825-d016-2b8b-763f71403739@oracle.com>
Message-ID: <0b21704e-8f05-1142-13d4-c17959407eee@oracle.com>

Any thoughts on this change?  -B

On 9/11/18 3:41 PM, Brent Christian wrote:
> Hi,
> 
> Please review this change to how the platform encoding is determined on 
> Mac when loading agents.
> 
> Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
> 
> Additional details in the bug report:
> https://bugs.openjdk.java.net/browse/JDK-8072130
> 
> Some background:
> Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding 
> hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), 
> the JDK uses UTF-8 instead; see JDK-8011194[1].? (This allowed apps 
> launched via double-clicked jar to display files correctly for non-ASCII 
> languages).
> 
> A similar encoding tweak was not made in the code path used for loading 
> agents.
> 
> This can come into play when an agent jar includes a Boot-Class-Path 
> entry containing non-ASCII characters.? iconv() gets setup to convert 
> UTF-8 to US-ASCII[2], but will fail when encountering extended 
> characters in the entry, so the path in question is not added to the 
> bootclasspath[3].? This will likely lead to a ClassNotFoundException.
> 
> When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a 
>  ?Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default 
>  ?encoding of UTF-8 (per 8011194) and creates Agent.jar with a 
> Boot-Class-Path that includes non-ASCII characters.? But the 
> Boot-Class-Path entry gets skipped when loading Agent.jar, so the 
> AgentSupport class can't be found.
> 
> I propose this be fixed by adding the same UTF-8 encoding adjustment on 
> MacOS from 8011194 to the agent loading code path.
> 
> An additional note:
> This bug was challenging to reproduce, in large part because the 8011194 
> code checks for an absent env var (getenv() == null), but not for env 
> vars with a blank/empty string value (getenv() == ""), so the test 
> environment had to be setup in a specific way (e.g. 'unset LANG' vs 
> 'export LANG=') to reproduce this bug.? So I'd like to update the code 
> to also check for empty string.? I also added a couple small 
> improvements to the test.
> 
> Thanks!
> 
> -Brent
> 
> 1. https://bugs.openjdk.java.net/browse/JDK-8011194
> 2. 
> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 
> 
> 3. 
> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873 
> 
> 

From huizhe.wang at oracle.com  Tue Sep 18 17:00:53 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 18 Sep 2018 10:00:53 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8210874: Test for JDK-8209615
Message-ID: <5BA12F45.5020307@oracle.com>

Hi Lance,

I accidentally missed checking in the test for JDK-8209615.

Here's the original webrev for JDK-8209615:
http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/

and here's the webrev for requesting checking in the test:
http://cr.openjdk.java.net/~joehw/jdk12/8210874/webrev/

I kept the @bug id and name of the test as 8209615.

Thanks,
Joe

From xueming.shen at oracle.com  Tue Sep 18 17:01:52 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 18 Sep 2018 10:01:52 -0700
Subject: RFR 12 : 8072130 :
 java/lang/instrument/BootClassPath/BootClassPathTest.sh
 fails on Mac OSX
In-Reply-To: <0b21704e-8f05-1142-13d4-c17959407eee@oracle.com>
References: <f708030e-d825-d016-2b8b-763f71403739@oracle.com>
 <0b21704e-8f05-1142-13d4-c17959407eee@oracle.com>
Message-ID: <5BA12F80.1020608@oracle.com>

+1

On 9/18/18, 9:42 AM, Brent Christian wrote:
> Any thoughts on this change?  -B
>
> On 9/11/18 3:41 PM, Brent Christian wrote:
>> Hi,
>>
>> Please review this change to how the platform encoding is determined 
>> on Mac when loading agents.
>>
>> Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
>>
>> Additional details in the bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8072130
>>
>> Some background:
>> Since JDK 8, if MacOS reports an encoding of US-ASCII, but no 
>> encoding hints are provided in environment variables (LANG, LC_ALL, 
>> LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1].  (This 
>> allowed apps launched via double-clicked jar to display files 
>> correctly for non-ASCII languages).
>>
>> A similar encoding tweak was not made in the code path used for 
>> loading agents.
>>
>> This can come into play when an agent jar includes a Boot-Class-Path 
>> entry containing non-ASCII characters.  iconv() gets setup to convert 
>> UTF-8 to US-ASCII[2], but will fail when encountering extended 
>> characters in the entry, so the path in question is not added to the 
>> bootclasspath[3].  This will likely lead to a ClassNotFoundException.
>>
>> When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run 
>> on a   Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a 
>> default   encoding of UTF-8 (per 8011194) and creates Agent.jar with 
>> a Boot-Class-Path that includes non-ASCII characters.  But the 
>> Boot-Class-Path entry gets skipped when loading Agent.jar, so the 
>> AgentSupport class can't be found.
>>
>> I propose this be fixed by adding the same UTF-8 encoding adjustment 
>> on MacOS from 8011194 to the agent loading code path.
>>
>> An additional note:
>> This bug was challenging to reproduce, in large part because the 
>> 8011194 code checks for an absent env var (getenv() == null), but not 
>> for env vars with a blank/empty string value (getenv() == ""), so the 
>> test environment had to be setup in a specific way (e.g. 'unset LANG' 
>> vs 'export LANG=') to reproduce this bug.  So I'd like to update the 
>> code to also check for empty string.  I also added a couple small 
>> improvements to the test.
>>
>> Thanks!
>>
>> -Brent
>>
>> 1. https://bugs.openjdk.java.net/browse/JDK-8011194
>> 2. 
>> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 
>>
>> 3. 
>> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873 
>>
>>


From mandy.chung at oracle.com  Tue Sep 18 17:10:31 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 18 Sep 2018 10:10:31 -0700
Subject: 8210496: Improve filtering for classes with security sensitive
 fields
In-Reply-To: <8b21c1d7-05a9-2cf4-d730-a7a48d976ccb@oracle.com>
References: <0590ee0e-a60e-a792-f222-ae7d0db946db@oracle.com>
 <ffee406e-5957-d030-f1c3-665f8619835a@oracle.com>
 <ba5b578f-6908-25dc-b2ba-db2165495971@gmail.com>
 <8b21c1d7-05a9-2cf4-d730-a7a48d976ccb@oracle.com>
Message-ID: <877666d2-dde8-252b-b921-f18c0672d445@oracle.com>



On 9/16/18 6:03 AM, Alan Bateman wrote:
>
> I've put a new webrev here, the only change is the replacement of the 
> old loop to use contains as you suggested:
> ? http://cr.openjdk.java.net/~alanb/8210496/2/webrev/index.html

Looks good.

Mandy

From naoto.sato at oracle.com  Tue Sep 18 17:41:22 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Sep 2018 10:41:22 -0700
Subject: [12] RFR: 8209880: tzdb.dat is not reproducibly built
Message-ID: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8209880/webrev.00/

The fix is to remove the use of HashSet/Map which is not guaranteed to 
preserve the same order on iteration.

Naoto

From lance.andersen at oracle.com  Tue Sep 18 17:46:31 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 18 Sep 2018 13:46:31 -0400
Subject: RFR(JDK12/JAXP/java.xml) 8210874: Test for JDK-8209615
In-Reply-To: <5BA12F45.5020307@oracle.com>
References: <5BA12F45.5020307@oracle.com>
Message-ID: <9DB950F7-43D4-493F-B506-5C97A3536DFD@oracle.com>

+1
> On Sep 18, 2018, at 1:00 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi Lance,
> 
> I accidentally missed checking in the test for JDK-8209615.
> 
> Here's the original webrev for JDK-8209615:
> http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/
> 
> and here's the webrev for requesting checking in the test:
> http://cr.openjdk.java.net/~joehw/jdk12/8210874/webrev/
> 
> I kept the @bug id and name of the test as 8209615.
> 
> 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 james.laskey at oracle.com  Tue Sep 18 17:51:57 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:51:57 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
Message-ID: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>

Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.

webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
csr: https://bugs.openjdk.java.net/browse/JDK-8202443

Cheers,

? Jim


From james.laskey at oracle.com  Tue Sep 18 17:51:56 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:51:56 -0300
Subject: RFR - JDK-8202443 - String::unescape (CSR Review)
Message-ID: <3BFC4A5E-25F0-4C7C-A1BF-A7DB5034FF0E@oracle.com>

Please review the API for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.

We decided to simplify the interface to the basics, i.e., translate all escape sequences.  No reciprocating method since the complexity of variations outweigh any likely need.

csr: https://bugs.openjdk.java.net/browse/JDK-8202443
jbs: https://bugs.openjdk.java.net/browse/JDK-8202442


Cheers,

? Jim


From james.laskey at oracle.com  Tue Sep 18 17:52:09 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:52:09 -0300
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
Message-ID: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>

Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.

webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
csr: https://bugs.openjdk.java.net/browse/JDK-8210718

Cheers,

? Jim


From james.laskey at oracle.com  Tue Sep 18 17:52:07 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:52:07 -0300
Subject: RFR - JDK-8210718 String::detab, String::entab (CSR Review)
Message-ID: <72A4872A-90D8-4DC8-9683-FD4A77340186@oracle.com>

Please review the API for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.

csr: https://bugs.openjdk.java.net/browse/JDK-8210718
jbs: https://bugs.openjdk.java.net/browse/JDK-8210717

Cheers,

? Jim



From james.laskey at oracle.com  Tue Sep 18 17:52:17 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:52:17 -0300
Subject: RFR - JDK-8203442 String::transform (Code Review)
Message-ID: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>

Please review the code for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String.

webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
csr: https://bugs.openjdk.java.net/browse/JDK-8203703

Cheers,

? Jim



From james.laskey at oracle.com  Tue Sep 18 17:52:16 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 14:52:16 -0300
Subject: RFR - JDK-8203703 String::transform (CSR Review)
Message-ID: <DB0440CA-2140-4ABF-9FAF-60891B57C7CF@oracle.com>

Please review the API for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String.

csr: https://bugs.openjdk.java.net/browse/JDK-8203703
jbs: https://bugs.openjdk.java.net/browse/JDK-8203442

Cheers,

? Jim



From james.laskey at oracle.com  Tue Sep 18 18:03:14 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 15:03:14 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
Message-ID: <F2885BF1-A93A-48F4-A069-E6A0AAD3BB34@oracle.com>

Do you mean the throws specifically? If so, of course.



> On Sep 18, 2018, at 2:51 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
> 
> Cheers,
> 
> ? Jim
> 


From james.laskey at oracle.com  Tue Sep 18 18:11:29 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 15:11:29 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <F2885BF1-A93A-48F4-A069-E6A0AAD3BB34@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <F2885BF1-A93A-48F4-A069-E6A0AAD3BB34@oracle.com>
Message-ID: <CE7033C0-1007-409F-87A1-E7DC687C58CE@oracle.com>

Revised to break up long exception statements;

webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-01/index.html

> On Sep 18, 2018, at 3:03 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Do you mean the throws specifically? If so, of course.
> 
> 
> 
>> On Sep 18, 2018, at 2:51 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>> 
>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>> 
>> Cheers,
>> 
>> ? Jim
>> 
> 


From erik.joelsson at oracle.com  Tue Sep 18 18:22:32 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 18 Sep 2018 11:22:32 -0700
Subject: [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
Message-ID: <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>

Looks good to me.

I guess it's hard to prove that the output is now stable, but time will 
tell.

/Erik


On 2018-09-18 10:41, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209880
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
>
> The fix is to remove the use of HashSet/Map which is not guaranteed to 
> preserve the same order on iteration.
>
> Naoto


From jonathan.gibbons at oracle.com  Tue Sep 18 18:33:38 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Sep 2018 11:33:38 -0700
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
Message-ID: <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>

Jim,

In JLS, and hence javac, Unicode escape handling happens early on at a 
low level, before string escape handling. This means that it is 
technically possible to write string escape sequences in terms of 
Unicode escapes.

I'm not suggesting you should do the same here, but you should be aware 
of the difference, compared to javac behavior.

-- Jon


On 9/18/18 10:51 AM, Jim Laskey wrote:
> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>
> Cheers,
>
> ? Jim
>


From roger.riggs at oracle.com  Tue Sep 18 18:48:12 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 18 Sep 2018 14:48:12 -0400
Subject: [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
Message-ID: <7e3fadd2-8adf-b832-79a6-2a896ec487aa@oracle.com>

Hi Naoto,

The elimination of duplicates and stable iteration should help.

+1

Roger

On 9/18/18 1:41 PM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209880
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
>
> The fix is to remove the use of HashSet/Map which is not guaranteed to 
> preserve the same order on iteration.
>
> Naoto


From james.laskey at oracle.com  Tue Sep 18 18:55:48 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 18 Sep 2018 15:55:48 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
Message-ID: <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>

The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.

So a developer could have

	String s = `
                   \t\tTitle
                   \t\t\tbody
		   ...

                   `.align().escape();

to have tabs inserted in the string.

"\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.

Cheers,

? Jim



> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Jim,
> 
> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
> 
> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
> 
> -- Jon
> 
> 
> On 9/18/18 10:51 AM, Jim Laskey wrote:
>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>> 
>> Cheers,
>> 
>> ? Jim
>> 
> 


From roger.riggs at oracle.com  Tue Sep 18 19:40:24 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 18 Sep 2018 15:40:24 -0400
Subject: RFR - JDK-8210718 String::detab, String::entab (CSR Review)
In-Reply-To: <72A4872A-90D8-4DC8-9683-FD4A77340186@oracle.com>
References: <72A4872A-90D8-4DC8-9683-FD4A77340186@oracle.com>
Message-ID: <ffcc3bfe-ea1e-2710-0783-d38d864954df@oracle.com>

Hi Jim,

It may be useful to be more specific about the definition of a tab stop.
In this context I think you mean the next multiple of 'n' greater than 
the current position + 1.
(And not taking into account surrogates, high and low) as 1 character or 2.
In some other contexts, tab stops can be specified as an explicit list 
of offsets from the start of the line.

Is there always at least one " " (space) replacing the tab?

In the exceptions, a typo: "less that equals"

In entab(), the "replaces some space characters... spacing aligns" seems 
a bit vague.
(I don't want to read the code to have a precise understanding.)

Thanks, Roger

On 9/18/18 1:52 PM, Jim Laskey wrote:
> Please review the API for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>
> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>
> Cheers,
>
> ? Jim
>
>


From huizhe.wang at oracle.com  Tue Sep 18 20:32:58 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 18 Sep 2018 13:32:58 -0700
Subject: RFR(JDK12/JAXP/java.xml) 8210874: Test for JDK-8209615
In-Reply-To: <9DB950F7-43D4-493F-B506-5C97A3536DFD@oracle.com>
References: <5BA12F45.5020307@oracle.com>
 <9DB950F7-43D4-493F-B506-5C97A3536DFD@oracle.com>
Message-ID: <5BA160FA.40703@oracle.com>

Thanks Lance!  It's done now.

Joe

On 9/18/18, 10:46 AM, Lance Andersen wrote:
> +1
>> On Sep 18, 2018, at 1:00 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi Lance,
>>
>> I accidentally missed checking in the test for JDK-8209615.
>>
>> Here's the original webrev for JDK-8209615:
>> http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk12/8209615/webrev/>
>>
>> and here's the webrev for requesting checking in the test:
>> http://cr.openjdk.java.net/~joehw/jdk12/8210874/webrev/
>>
>> I kept the @bug id and name of the test as 8209615.
>>
>> 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 naoto.sato at oracle.com  Tue Sep 18 20:55:39 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Sep 2018 13:55:39 -0700
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
Message-ID: <6ea7d0fa-114e-1503-ecec-80b23d499d4b@oracle.com>

Hi Jim,

At the last sentence in the method description, there's a line 
"otherwise a CharacterCodingException may occur during UTF-8 decoding." 
It's not decoding into UTF-8, so simply "during decoding (or 
unescaping)" sounds better to me.

Naoto

On 9/18/18 10:51 AM, Jim Laskey wrote:
> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
> 
> Cheers,
> 
> ? Jim
> 

From xueming.shen at oracle.com  Wed Sep 19 00:14:30 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 18 Sep 2018 17:14:30 -0700
Subject: RFR JDK-8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32
 mistakenly set the crc32 value into size field
Message-ID: <5BA194E6.5000600@oracle.com>

Hi,

Please help codereview the change for JDK-8210899.

issue: https://bugs.openjdk.java.net/browse/JDK-8210899
webrev: http://cr.openjdk.java.net/~sherman/8210899/webrev

Thanks,
Sherman

From brian.burkhalter at oracle.com  Wed Sep 19 00:50:21 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Sep 2018 17:50:21 -0700
Subject: RFR JDK-8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32
 mistakenly set the crc32 value into size field
In-Reply-To: <5BA194E6.5000600@oracle.com>
References: <5BA194E6.5000600@oracle.com>
Message-ID: <851D0181-5EF1-4875-B2A2-5DE4375CF76E@oracle.com>

Hi Sherman,

This looks fine to me.

Does the current code fail both of the added checks in the test?

Thanks,

Brian

On Sep 18, 2018, at 5:14 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Please help codereview the change for JDK-8210899.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8210899
> webrev: http://cr.openjdk.java.net/~sherman/8210899/webrev


From xueming.shen at oracle.com  Wed Sep 19 01:45:36 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 18 Sep 2018 18:45:36 -0700
Subject: RFR JDK-8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32
 mistakenly set the crc32 value into size field
In-Reply-To: <851D0181-5EF1-4875-B2A2-5DE4375CF76E@oracle.com>
References: <5BA194E6.5000600@oracle.com>
 <851D0181-5EF1-4875-B2A2-5DE4375CF76E@oracle.com>
Message-ID: <5BA1AA40.4090803@oracle.com>

On 9/18/18, 5:50 PM, Brian Burkhalter wrote:
> Hi Sherman,
>
> This looks fine to me.
>
> Does the current code fail both of the added checks in the test?

Hi Brian,

Thanks looking into it.

Yes, the current code (with the change for JDK-8034802) fails both of 
the added
checks.

Thanks,
Shermzn



>
> Thanks,
>
> Brian
>
> On Sep 18, 2018, at 5:14 PM, Xueming Shen <xueming.shen at oracle.com 
> <mailto:xueming.shen at oracle.com>> wrote:
>
>> Please help codereview the change for JDK-8210899.
>>
>> issue:https://bugs.openjdk.java.net/browse/JDK-8210899
>> webrev:http://cr.openjdk.java.net/~sherman/8210899/webrev 
>> <http://cr.openjdk.java.net/%7Esherman/8210899/webrev>
>


From andrej.golovnin at gmail.com  Wed Sep 19 07:20:39 2018
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 19 Sep 2018 09:20:39 +0200
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
In-Reply-To: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
References: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
Message-ID: <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>

Hi Jim,

I'm not native english speaker. But that does not seem to be right for me:

2983      * @throws IllegalArgumentException if n is less that equals to zero.

3029      * @throws IllegalArgumentException if n is less that equals to zero.

I would write it as: if n is less than or equals to zero.

Best regards,
Andrej Golovnin
On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey <james.laskey at oracle.com> wrote:
>
> Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>
> Cheers,
>
> ? Jim
>

From magnus.ihse.bursie at oracle.com  Wed Sep 19 08:01:43 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Sep 2018 10:01:43 +0200
Subject: [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
Message-ID: <568016a9-4332-f2fd-4942-fc3a0cda7f91@oracle.com>


On 2018-09-18 19:41, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209880
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
Looks good. Thank you for fixing this!

/Magnus

>
> The fix is to remove the use of HashSet/Map which is not guaranteed to 
> preserve the same order on iteration.
>
> Naoto


From james.laskey at oracle.com  Wed Sep 19 12:31:30 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 09:31:30 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <6ea7d0fa-114e-1503-ecec-80b23d499d4b@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <6ea7d0fa-114e-1503-ecec-80b23d499d4b@oracle.com>
Message-ID: <7AE875E3-FA23-47F7-9D87-0E6C7A304D51@oracle.com>

Updated.

> On Sep 18, 2018, at 5:55 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hi Jim,
> 
> At the last sentence in the method description, there's a line "otherwise a CharacterCodingException may occur during UTF-8 decoding." It's not decoding into UTF-8, so simply "during decoding (or unescaping)" sounds better to me.
> 
> Naoto
> 
> On 9/18/18 10:51 AM, Jim Laskey wrote:
>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>> Cheers,
>> ? Jim


From james.laskey at oracle.com  Wed Sep 19 12:35:49 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 09:35:49 -0300
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
In-Reply-To: <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>
References: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
 <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>
Message-ID: <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>

Thank you.  Updated.

> On Sep 19, 2018, at 4:20 AM, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
> 
> Hi Jim,
> 
> I'm not native english speaker. But that does not seem to be right for me:
> 
> 2983      * @throws IllegalArgumentException if n is less that equals to zero.
> 
> 3029      * @throws IllegalArgumentException if n is less that equals to zero.
> 
> I would write it as: if n is less than or equals to zero.
> 
> Best regards,
> Andrej Golovnin
> On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey <james.laskey at oracle.com> wrote:
>> 
>> Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>> 
>> Cheers,
>> 
>> ? Jim
>> 


From forax at univ-mlv.fr  Wed Sep 19 12:58:36 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 19 Sep 2018 14:58:36 +0200 (CEST)
Subject: RFR - JDK-8203442 String::transform (Code Review)
In-Reply-To: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
Message-ID: <1670342068.590437.1537361916959.JavaMail.zimbra@u-pem.fr>

Hi Jim,
the signature of transform() in the webrev was not updated (so the wildcards are missing).

And i'm still not convince this method should be introduced as is:
- it need more variants (transformToInt, transformToLong, transformToDouble) to be useful, currently "foo".transform(String::length) do box the resulting int to an Integer.
- pull it's own weight, while it's nice to be able to be able to write code fluently from left to right, "foo".transform(Utils::capitalizeFirstLetter), you can say exactly the same thing for all classes in the JDK, e.g. path.transform(Utils.appendTextSuffix). Other languages have introduced an operator to solve that issue (function call syntax is not fluent) like by example the operator '|>' as in "foo" |> Utils.capitalizeFirstLetter.

regards,
R?mi

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 18 Septembre 2018 19:52:17
> Objet: RFR - JDK-8203442 String::transform (Code Review)

> Please review the code for String::transform. The goal is to provide a String
> instance method to allow function application of custom transformations applied
> to an instance of String.
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
> 
> Cheers,
> 
> ? Jim

From scolebourne at joda.org  Wed Sep 19 13:25:48 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 19 Sep 2018 14:25:48 +0100
Subject: RFR - JDK-8203703 String::transform (CSR Review)
In-Reply-To: <DB0440CA-2140-4ABF-9FAF-60891B57C7CF@oracle.com>
References: <DB0440CA-2140-4ABF-9FAF-60891B57C7CF@oracle.com>
Message-ID: <CACzrW9B55krP+izNCnasgKcRR_H_hj21kAq6g2Da2ED2KQqEOg@mail.gmail.com>

On Tue, 18 Sep 2018 at 18:57, Jim Laskey <james.laskey at oracle.com> wrote:
>
> Please review the API for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String.
>
> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442

The similar method in java.time.* is named `with`
https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/time/LocalDate.html#with(java.time.temporal.TemporalAdjuster)

String capped =
  title.with(Example::naiveDropFirstWord);
       .with(Example::naiveTitleCase)
       .concat(".");

However, I note that this method is designed to return any type, not
just String (making it a different kind of method). But *why* return
any type? The motivation for doing so is not clear from the CSR.

Stephen

From james.laskey at oracle.com  Wed Sep 19 13:35:49 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 10:35:49 -0300
Subject: RFR - JDK-8203442 String::transform (Code Review)
In-Reply-To: <1670342068.590437.1537361916959.JavaMail.zimbra@u-pem.fr>
References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
 <1670342068.590437.1537361916959.JavaMail.zimbra@u-pem.fr>
Message-ID: <4E786D5D-B7E5-4482-95C9-38658D29321B@oracle.com>

> On Sep 19, 2018, at 9:58 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Jim,
> the signature of transform() in the webrev was not updated (so the wildcards are missing).

Apologies.  I created the webrev before I fully saved. Will update in a bit.


> 
> And i'm still not convince this method should be introduced as is:
> - it need more variants (transformToInt, transformToLong, transformToDouble) to be useful, currently "foo".transform(String::length) do box the resulting int to an Integer.
> - pull it's own weight, while it's nice to be able to be able to write code fluently from left to right, "foo".transform(Utils::capitalizeFirstLetter), you can say exactly the same thing for all classes in the JDK, e.g. path.transform(Utils.appendTextSuffix). Other languages have introduced an operator to solve that issue (function call syntax is not fluent) like by example the operator '|>' as in "foo" |> Utils.capitalizeFirstLetter.
> 

I hear you. Wouldn?t it be nice to have an Object::transform. Won't happen since it would likely break the world. You could push for something |> method(?) which applies static R method(T fakeThis, ?), but that will take years of debate.  String::transform was intended to facilitate custom manipulation (alignment) of raw string literals, in the most string generalized way. I?ll  discuss the other variants but please provide better use cases.

Cheers,

? Jim




> regards,
> R?mi
> 
> ----- Mail original -----
>> De: "Jim Laskey" <james.laskey at oracle.com>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Mardi 18 Septembre 2018 19:52:17
>> Objet: RFR - JDK-8203442 String::transform (Code Review)
> 
>> Please review the code for String::transform. The goal is to provide a String
>> instance method to allow function application of custom transformations applied
>> to an instance of String.
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
>> 
>> Cheers,
>> 
>> ? Jim


From james.laskey at oracle.com  Wed Sep 19 13:51:19 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 10:51:19 -0300
Subject: RFR - JDK-8203703 String::transform (CSR Review)
In-Reply-To: <CACzrW9B55krP+izNCnasgKcRR_H_hj21kAq6g2Da2ED2KQqEOg@mail.gmail.com>
References: <DB0440CA-2140-4ABF-9FAF-60891B57C7CF@oracle.com>
 <CACzrW9B55krP+izNCnasgKcRR_H_hj21kAq6g2Da2ED2KQqEOg@mail.gmail.com>
Message-ID: <24F1353A-726E-4DF0-A3AE-F6C4D01BCCBB@oracle.com>

I?m not married to the name (I suggested apply). ?with? also works. The originating goal was to allow custom alignment methods for those developers not satisfied with String::align(). String would logically be the result. ?transform" became generic when the case was made that other types might also be relevant.

Example:

	import mystuff.HTMLDocument;

	HTMLDocument html = `
                       <html>
                           <body>
                               <p>Hello World.</p>
                           </body>
                       </html>
                  `.transform(HTMLDocument::parse);

Not a strong argument. Along with Remi?s request for primitive variants, I might be lead back to just supporting String.

Cheers,

? Jim


> On Sep 19, 2018, at 10:25 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> On Tue, 18 Sep 2018 at 18:57, Jim Laskey <james.laskey at oracle.com> wrote:
>> 
>> Please review the API for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String.
>> 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
> 
> The similar method in java.time.* is named `with`
> https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/time/LocalDate.html#with(java.time.temporal.TemporalAdjuster)
> 
> String capped =
>  title.with(Example::naiveDropFirstWord);
>       .with(Example::naiveTitleCase)
>       .concat(".");
> 
> However, I note that this method is designed to return any type, not
> just String (making it a different kind of method). But *why* return
> any type? The motivation for doing so is not clear from the CSR.
> 
> Stephen


From jan.lahoda at oracle.com  Wed Sep 19 14:10:44 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 19 Sep 2018 16:10:44 +0200
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
Message-ID: <5BA258E4.8060404@oracle.com>

I guess Jon's comment was that (per JLS) the outcome of unicode 
unescapes can then participate in the escape sequences in String 
literals. So, this:
"\u005ct"

is (as far as I know) a single character-literal (a tab), while it seems 
that
`\u005ct`.unescape()

is two characters:
\t

Not sure if that's an intent or not.

Jan

On 18.9.2018 20:55, Jim Laskey wrote:
> The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.
>
> So a developer could have
>
> 	String s = `
>                     \t\tTitle
>                     \t\t\tbody
> 		   ...
>
>                     `.align().escape();
>
> to have tabs inserted in the string.
>
> "\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.
>
> Cheers,
>
> ? Jim
>
>
>
>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Jim,
>>
>> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
>>
>> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
>>
>> -- Jon
>>
>>
>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>>>
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>
>>> Cheers,
>>>
>>> ? Jim
>>>
>>
>

From jonathan.gibbons at oracle.com  Wed Sep 19 14:33:18 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Sep 2018 07:33:18 -0700
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <5BA258E4.8060404@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
 <5BA258E4.8060404@oracle.com>
Message-ID: <63589f00-0bed-3a4f-5bc5-86f2d78259fd@oracle.com>

Jan,

Yes, thanks for clarifying my comment.

And to repeat, my comment was just to raise awareness in the different 
treatment according to JLS and to .unescape().

-- Jon


On 9/19/18 7:10 AM, Jan Lahoda wrote:
> I guess Jon's comment was that (per JLS) the outcome of unicode 
> unescapes can then participate in the escape sequences in String 
> literals. So, this:
> "\u005ct"
>
> is (as far as I know) a single character-literal (a tab), while it 
> seems that
> `\u005ct`.unescape()
>
> is two characters:
> \t
>
> Not sure if that's an intent or not.
>
> Jan
>
> On 18.9.2018 20:55, Jim Laskey wrote:
>> The intent, of course, is to offset the raw string literals 
>> non-translation of Unicode escapes and escape sequences. That is, 
>> have the multi-line cake and eat the escapes too.
>>
>> So a developer could have
>>
>> ????String s = `
>> ??????????????????? \t\tTitle
>> ??????????????????? \t\t\tbody
>> ?????????? ...
>>
>> ??????????????????? `.align().escape();
>>
>> to have tabs inserted in the string.
>>
>> "\\" "\u005c\u005c" and `\` all translate to the same string. 
>> `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates 
>> to be the same as "\\?, "\u005c\u005c" and `\`.
>>
>> Cheers,
>>
>> ? Jim
>>
>>
>>
>>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons 
>>> <jonathan.gibbons at oracle.com> wrote:
>>>
>>> Jim,
>>>
>>> In JLS, and hence javac, Unicode escape handling happens early on at 
>>> a low level, before string escape handling. This means that it is 
>>> technically possible to write string escape sequences in terms of 
>>> Unicode escapes.
>>>
>>> I'm not suggesting you should do the same here, but you should be 
>>> aware of the difference, compared to javac behavior.
>>>
>>> -- Jon
>>>
>>>
>>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>>> Please review the code for String::unescape. Used to translate 
>>>> escape sequences in a string, typically in a raw string literal, 
>>>> into characters represented by those escapes.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>>
>>>> Cheers,
>>>>
>>>> ? Jim
>>>>
>>>
>>


From brian.burkhalter at oracle.com  Wed Sep 19 14:34:34 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Sep 2018 07:34:34 -0700
Subject: RFR JDK-8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32
 mistakenly set the crc32 value into size field
In-Reply-To: <5BA1AA40.4090803@oracle.com>
References: <5BA194E6.5000600@oracle.com>
 <851D0181-5EF1-4875-B2A2-5DE4375CF76E@oracle.com>
 <5BA1AA40.4090803@oracle.com>
Message-ID: <7EDAC38A-B7A6-434B-879E-7EC303EB745F@oracle.com>

Hi Sherman

On Sep 18, 2018, at 6:45 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Thanks looking into it.

You?re welcome.

> Yes, the current code (with the change for JDK-8034802) fails both of the added
> checks. 

Thanks for the update.

Brian

From james.laskey at oracle.com  Wed Sep 19 14:40:05 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 11:40:05 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <5BA258E4.8060404@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
 <5BA258E4.8060404@oracle.com>
Message-ID: <B10339BE-2FDD-48D8-B99B-BE00F581BF73@oracle.com>

I see and good point.  I think Jon is correct.  If you are using the JLS as the basis of your argument, then you better damn well stick to the JLS.

I?ll make the changes.

Cheers,

? Jim


> On Sep 19, 2018, at 11:10 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then participate in the escape sequences in String literals. So, this:
> "\u005ct"
> 
> is (as far as I know) a single character-literal (a tab), while it seems that
> `\u005ct`.unescape()
> 
> is two characters:
> \t
> 
> Not sure if that's an intent or not.
> 
> Jan
> 
> On 18.9.2018 20:55, Jim Laskey wrote:
>> The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.
>> 
>> So a developer could have
>> 
>> 	String s = `
>>                    \t\tTitle
>>                    \t\t\tbody
>> 		   ...
>> 
>>                    `.align().escape();
>> 
>> to have tabs inserted in the string.
>> 
>> "\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.
>> 
>> Cheers,
>> 
>> ? Jim
>> 
>> 
>> 
>>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>> 
>>> Jim,
>>> 
>>> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
>>> 
>>> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
>>> 
>>> -- Jon
>>> 
>>> 
>>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>> 
>>>> Cheers,
>>>> 
>>>> ? Jim
>>>> 
>>> 
>> 


From jonathan.gibbons at oracle.com  Wed Sep 19 14:42:54 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Sep 2018 07:42:54 -0700
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <B10339BE-2FDD-48D8-B99B-BE00F581BF73@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
 <5BA258E4.8060404@oracle.com>
 <B10339BE-2FDD-48D8-B99B-BE00F581BF73@oracle.com>
Message-ID: <b0b31605-c1ca-71e4-482a-7a143ee52b60@oracle.com>

If you're making the change, then you might add a test case based on 
Jan's suggestion, testing

 ??? "\u005ct".equals(`\u005ct`.unescape())

-- Jon


On 9/19/18 7:40 AM, Jim Laskey wrote:
> I see and good point.  I think Jon is correct.  If you are using the JLS as the basis of your argument, then you better damn well stick to the JLS.
>
> I?ll make the changes.
>
> Cheers,
>
> ? Jim
>
>
>> On Sep 19, 2018, at 11:10 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>
>> I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then participate in the escape sequences in String literals. So, this:
>> "\u005ct"
>>
>> is (as far as I know) a single character-literal (a tab), while it seems that
>> `\u005ct`.unescape()
>>
>> is two characters:
>> \t
>>
>> Not sure if that's an intent or not.
>>
>> Jan
>>
>> On 18.9.2018 20:55, Jim Laskey wrote:
>>> The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.
>>>
>>> So a developer could have
>>>
>>> 	String s = `
>>>                     \t\tTitle
>>>                     \t\t\tbody
>>> 		   ...
>>>
>>>                     `.align().escape();
>>>
>>> to have tabs inserted in the string.
>>>
>>> "\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.
>>>
>>> Cheers,
>>>
>>> ? Jim
>>>
>>>
>>>
>>>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> Jim,
>>>>
>>>> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
>>>>
>>>> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>>>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>>>
>>>>> Cheers,
>>>>>
>>>>> ? Jim
>>>>>


From james.laskey at oracle.com  Wed Sep 19 14:57:24 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 11:57:24 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <b0b31605-c1ca-71e4-482a-7a143ee52b60@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
 <5BA258E4.8060404@oracle.com>
 <B10339BE-2FDD-48D8-B99B-BE00F581BF73@oracle.com>
 <b0b31605-c1ca-71e4-482a-7a143ee52b60@oracle.com>
Message-ID: <ABAC04BB-30FC-449F-9EFF-C16D36F53F9C@oracle.com>

Will do.


> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons <Jonathan.Gibbons at oracle.com> wrote:
> 
> If you're making the change, then you might add a test case based on Jan's suggestion, testing
> 
>     "\u005ct".equals(`\u005ct`.unescape())
> 
> -- Jon
> 
> 
> On 9/19/18 7:40 AM, Jim Laskey wrote:
>> I see and good point.  I think Jon is correct.  If you are using the JLS as the basis of your argument, then you better damn well stick to the JLS.
>> 
>> I?ll make the changes.
>> 
>> Cheers,
>> 
>> ? Jim
>> 
>> 
>>> On Sep 19, 2018, at 11:10 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>> 
>>> I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then participate in the escape sequences in String literals. So, this:
>>> "\u005ct"
>>> 
>>> is (as far as I know) a single character-literal (a tab), while it seems that
>>> `\u005ct`.unescape()
>>> 
>>> is two characters:
>>> \t
>>> 
>>> Not sure if that's an intent or not.
>>> 
>>> Jan
>>> 
>>> On 18.9.2018 20:55, Jim Laskey wrote:
>>>> The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.
>>>> 
>>>> So a developer could have
>>>> 
>>>> 	String s = `
>>>>                    \t\tTitle
>>>>                    \t\t\tbody
>>>> 		   ...
>>>> 
>>>>                    `.align().escape();
>>>> 
>>>> to have tabs inserted in the string.
>>>> 
>>>> "\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.
>>>> 
>>>> Cheers,
>>>> 
>>>> ? Jim
>>>> 
>>>> 
>>>> 
>>>>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>>> 
>>>>> Jim,
>>>>> 
>>>>> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
>>>>> 
>>>>> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
>>>>> 
>>>>> -- Jon
>>>>> 
>>>>> 
>>>>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>>>>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> ? Jim
>>>>>> 
> 


From james.laskey at oracle.com  Wed Sep 19 15:02:35 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 12:02:35 -0300
Subject: RFR - JDK-8210718 String::detab, String::entab (CSR Review)
In-Reply-To: <ffcc3bfe-ea1e-2710-0783-d38d864954df@oracle.com>
References: <72A4872A-90D8-4DC8-9683-FD4A77340186@oracle.com>
 <ffcc3bfe-ea1e-2710-0783-d38d864954df@oracle.com>
Message-ID: <5B8F1788-2C4D-4BF2-B382-3563241B9D9A@oracle.com>



> On Sep 18, 2018, at 4:40 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi Jim,
> 
> It may be useful to be more specific about the definition of a tab stop.

Agree.

> In this context I think you mean the next multiple of 'n' greater than the current position + 1.
> (And not taking into account surrogates, high and low) as 1 character or 2.

Oops - missed the surrogates issue.  Need to modify StringUTF-16 to account for surrogate-pair is one character.

> In some other contexts, tab stops can be specified as an explicit list of offsets from the start of the line.

Are you suggesting an overload method that takes an array of int (tab stops)?  I can see the value, but use case size is likely small.

> 
> Is there always at least one " " (space) replacing the tab?

Yes. ?\tX?.detab(1)  -> ?.X? and ?X\tX?.detab(1)  -> ?X.X? 

> 
> In the exceptions, a typo: "less that equals?

Updated.

> 
> In entab(), the "replaces some space characters... spacing aligns" seems a bit vague.
> (I don't want to read the code to have a precise understanding.)

Will reword and post an update.

> 
> Thanks, Roger
> 
> On 9/18/18 1:52 PM, Jim Laskey wrote:
>> Please review the API for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>> 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>> 
>> Cheers,
>> 
>> ? Jim
>> 
>> 
> 


From james.laskey at oracle.com  Wed Sep 19 16:01:26 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 13:01:26 -0300
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
In-Reply-To: <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>
References: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
 <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>
 <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>
Message-ID: <43D33838-66B7-4F09-A75B-6073EEC7BF5B@oracle.com>

webrev updated

http://cr.openjdk.java.net/~jlaskey/8210717/webrev-01/index.html <http://cr.openjdk.java.net/~jlaskey/8210717/webrev-01/index.html>


> On Sep 19, 2018, at 9:35 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Thank you.  Updated.
> 
>> On Sep 19, 2018, at 4:20 AM, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
>> 
>> Hi Jim,
>> 
>> I'm not native english speaker. But that does not seem to be right for me:
>> 
>> 2983      * @throws IllegalArgumentException if n is less that equals to zero.
>> 
>> 3029      * @throws IllegalArgumentException if n is less that equals to zero.
>> 
>> I would write it as: if n is less than or equals to zero.
>> 
>> Best regards,
>> Andrej Golovnin
>> On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey <james.laskey at oracle.com> wrote:
>>> 
>>> Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>>> 
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>>> 
>>> Cheers,
>>> 
>>> ? Jim
>>> 
> 


From james.laskey at oracle.com  Wed Sep 19 16:10:46 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 19 Sep 2018 13:10:46 -0300
Subject: RFR - JDK-8203442 String::transform (Code Review)
In-Reply-To: <4E786D5D-B7E5-4482-95C9-38658D29321B@oracle.com>
References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
 <1670342068.590437.1537361916959.JavaMail.zimbra@u-pem.fr>
 <4E786D5D-B7E5-4482-95C9-38658D29321B@oracle.com>
Message-ID: <9803F7AE-280B-4830-AEAD-601FBE1F1A1A@oracle.com>

updated webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev-01/index.html <http://cr.openjdk.java.net/~jlaskey/8203442/webrev-01/index.html>

> On Sep 19, 2018, at 10:35 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
>> On Sep 19, 2018, at 9:58 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Jim,
>> the signature of transform() in the webrev was not updated (so the wildcards are missing).
> 
> Apologies.  I created the webrev before I fully saved. Will update in a bit.
> 
> 
>> 
>> And i'm still not convince this method should be introduced as is:
>> - it need more variants (transformToInt, transformToLong, transformToDouble) to be useful, currently "foo".transform(String::length) do box the resulting int to an Integer.
>> - pull it's own weight, while it's nice to be able to be able to write code fluently from left to right, "foo".transform(Utils::capitalizeFirstLetter), you can say exactly the same thing for all classes in the JDK, e.g. path.transform(Utils.appendTextSuffix). Other languages have introduced an operator to solve that issue (function call syntax is not fluent) like by example the operator '|>' as in "foo" |> Utils.capitalizeFirstLetter.
>> 
> 
> I hear you. Wouldn?t it be nice to have an Object::transform. Won't happen since it would likely break the world. You could push for something |> method(?) which applies static R method(T fakeThis, ?), but that will take years of debate.  String::transform was intended to facilitate custom manipulation (alignment) of raw string literals, in the most string generalized way. I?ll  discuss the other variants but please provide better use cases.
> 
> Cheers,
> 
> ? Jim
> 
> 
> 
> 
>> regards,
>> R?mi
>> 
>> ----- Mail original -----
>>> De: "Jim Laskey" <james.laskey at oracle.com>
>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Mardi 18 Septembre 2018 19:52:17
>>> Objet: RFR - JDK-8203442 String::transform (Code Review)
>> 
>>> Please review the code for String::transform. The goal is to provide a String
>>> instance method to allow function application of custom transformations applied
>>> to an instance of String.
>>> 
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
>>> 
>>> Cheers,
>>> 
>>> ? Jim
> 


From akashche at redhat.com  Tue Sep 18 20:35:05 2018
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 18 Sep 2018 21:35:05 +0100
Subject: [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
 <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>
Message-ID: <b133cc4e-bada-ec78-fbb1-55f0ff5a66e5@redhat.com>

Hi,

On 09/18/2018 07:22 PM, Erik Joelsson wrote:
> Looks good to me.
> 
> I guess it's hard to prove that the output is now stable, but time will 
> tell.
> 
> /Erik
> 
> 
> On 2018-09-18 10:41, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209880
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
>>
>> The fix is to remove the use of HashSet/Map which is not guaranteed to 
>> preserve the same order on iteration.

+1 to this change, I've got bitten by this some years ago - 
http://mail.openjdk.java.net/pipermail/i18n-dev/2015-April/001671.html


-- 
-Alex

From pallavi.sonal at oracle.com  Wed Sep 19 17:15:24 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Wed, 19 Sep 2018 10:15:24 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
Message-ID: <38b8864c-e283-44f7-a962-aa65fb560b79@default>

Hi,

Please review the changes to the following issue:

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

 

The proposed fix is located at:

Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/

 

As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.

 

[1] https://en.wikipedia.org/wiki/ISO_8601 

 

Thanks,

Pallavi Sonal

 

 

From igor.ignatyev at oracle.com  Wed Sep 19 17:18:36 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 19 Sep 2018 10:18:36 -0700
Subject: RFR(M) : 8210894 : remove jdk/testlibrary/Asserts 
Message-ID: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
> 1188 lines changed: 252 ins; 591 del; 345 mod; 

Hi all,

could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.

webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac

Thanks,
-- Igor

From stuart.marks at oracle.com  Wed Sep 19 17:36:03 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 19 Sep 2018 10:36:03 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
Message-ID: <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>

Hi Jaikiran,

Thanks for doing the updates and sending the patch.

Replies to your comments follow.

> While adding this, I realized that the current javadoc doesn't mention
> anything about the behaviour of this method when a null array is passed
> to it. The implementation currently throws a NullPointerException. So I
> went ahead and updated the javadoc to include:
> 
>      * @throws NullPointerException if the passed array is {@code null}

Strictly speaking this isn't necessary, as the class doc has the following 
statement:

>  * <p>The methods in this class all throw a {@code NullPointerException},
>  * if the specified array reference is null, except where noted.

However, since Arrays.asList is quite heavily used, and it's something of an 
outlier among the other Arrays methods, I think it's OK to add the @throws line. 
(There are a few other methods in this class that also have such @throws lines.)

>>  - add a note emphasizing that the returned list is NOT unmodifiable.
>> it's a common mistake to assume that it is. I'd also put in a
>> reference to List.html#unmodifiable here in case people do want an
>> unmodifiable list.
> 
> Done. I looked up the javadoc style guide[1] (is that still relevant,
> especially for contributions to the JDK itself?) and javadoc of some
> "recent" files within the JDK code, to see what's the current way to
> emphasize certain parts of the comments. I couldn't find anything
> conclusive, so I decided to use "<em>". Let me know if there's some
> other preferred way.

> [1] http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide

The JDK has a mixture of "<em>" vs "<i>" markup. Since you want to provide 
emphasis, "<em>" seems sensible. (Note, I've modified this further; see below.)

The javadoc style guide is quite old and many parts are out of date, but many 
parts are still valid. For example, it's still a strong convention that a method 
doc's initial sentence be a verb phrase (not a complete sentence) in the 
indicative (not imperative) mood. For example, the summary sentence of this 
method's doc is:

     Returns a fixed-size list backed by the specified array.

and it is not

     Return a fixed-size list backed by the specified array.

and it is also not

     This method returns a fixed-size list backed by the specified array.

However, the javadoc style guide mentions use of <code>...</code> markup, which 
has superseded by the javadoc {@code ...} inline tag. I think that tag was 
introduced more recently than the javadoc style guide was last updated.

**

The patch you sent is pretty good as it stands, but there were a couple minor 
things that I think could still be improved. In the interest of time, instead of 
asking you to make the changes, I went ahead and modified the patch myself. The 
modifications are as follows:

-     * <p>The returned list can be changed only in certain ways. Operations
-     * that would change the size of the returned list leave the list unchanged
-     * and throw {@link UnsupportedOperationException}.

The first sentence didn't seem right to me, as it's quite vague. After some 
thought it finally occurred to me that what's necessary is a statement about the 
optional methods of the Collection interface. I've edited this paragraph thus:

+     * <p>The returned list implements the optional Collection methods, except 
those
+     * that would change the size of the returned list. Those methods leave
+     * the list unchanged and throw {@link UnsupportedOperationException}.

In the last paragraph I inverted the sense of "not unmodifiable" and added a 
link to the Collections.unmodifiableList method.

+     * <p>The list returned by this method <em>is modifiable.</em>
+     * To create an unmodifiable list, see
+     * {@link Collections#unmodifiableList Collections.unmodifiableList}
+     * or <a href="List.html#unmodifiable">Unmodifiable Lists</a>.

I've changed the <pre></pre> code samples to use <pre>{@code ...}</pre>. This 
allows use of < and > instead of HTML entities &lt; and &gt;.

Finally, I had to change the changeset metadata to conform to the OpenJDK rules. 
Specifically, the changeset author is required to be an OpenJDK user name. Since 
you don't have one, I've listed your email address in the Contributed-by line of 
the changeset comment.

I've attached the modified patch. If you're ok with it, I'll proceed with filing 
a CSR.

Thanks,

s'marks





On 9/15/18 1:49 AM, Jaikiran Pai wrote:
> Hello Stuart,
> 
> Thank you very much for the detailed review. I have attached an updated
> patch which incorporates the suggested changes. The complete javadoc
> text is included inline here and a few comments are inline in the rest
> of this mail:
> 
>  ??? /**
>  ???? * Returns a fixed-size list backed by the specified array. Changes
> made to
>  ???? * the array will be visible in the returned list, and changes made
> to the
>  ???? * list will be visible in the array. The returned list is
>  ???? * {@link Serializable} and implements {@link RandomAccess}.
>  ???? *
>  ???? * <p>The returned list can be changed only in certain ways. Operations
>  ???? * that would change the size of the returned list leave the list
> unchanged
>  ???? * and throw {@link UnsupportedOperationException}.
>  ???? *
>  ???? * @apiNote
>  ???? * This method acts as bridge between array-based and collection-based
>  ???? * APIs, in combination with {@link Collection#toArray}.
>  ???? *
>  ???? * <p>This method provides a way to wrap an existing array:
>  ???? * <pre>
>  ???? *???? Integer[] numbers = ...
>  ???? *???? ...
>  ???? *???? List&lt;Integer&gt; values = Arrays.asList(numbers);
>  ???? * </pre>
>  ???? *
>  ???? * <p>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 list returned by this method is <em>not</em>
>  ???? * <a href="{@docRoot}/java.base/java/util/List.html#unmodifiable">
>  ???? * unmodifiable</a>
>  ???? *
>  ???? * @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
>  ???? * @throws NullPointerException if the passed array is {@code null}
>  ???? */
> 
> 
> On 11/09/18 7:54 AM, Stuart Marks wrote:
>>
>>
>>> The passed array is held as a reference in the returned list.
>>
>> While this is true, this is really a statement about implementation.
>> For the specification, we want to focus on assertions about the
>> behavior. Please remove.
> 
> Done.
>>
>>> 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.
>>
>> This is an improvement on the original "(Changes to the returned list
>> "write through" to the array)" which doesn't describe the behavior
>> precisely enough nor does it discuss the "bi-directional" nature of
>> visibility of the changes. The proposed text is a bit verbose,
>> however; I'd suggest the following:
>>
>>  ??? Changes made to the array will be visible in the returned list, and
>>  ??? changes made to the list will be visible in the array.
> 
> Done. I agree the my previous version in the patch was verbose and what
> you suggest looks better.
>>
>>
>>> The returned list is serializable and implements {@link RandomAccess}.
>>
>> (This was from the original text.) It's kind of odd that RandomAccess
>> is a link but Serializable is not. I'd suggest making Serializable a
>> link as follows:
> 
> Done.
>>
>>>  ???? * <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.
>>
>> This text would be fine for something like a tutorial, but it's not
>> precise enough in that it describes behavior by example ("operations
>> like...") and it doesn't specify the behavior if a disallowed
>> operation is performed. I'd suggest this instead:
>>
>>  ??? Operations that would change the size of the returned list leave the
>>  ??? list unchanged and throw {@link UnsupportedOperationException}.
> 
> Done.
>>
>>
>> Listing the exact methods that can change the size is unwise, as it
>> can change over time and the list will become out of date. There are
>> also a lot of obscure ways to change the size of a list besides
>> methods on the list, e.g. via an iterator's remove(), a sublist's
>> size-change method, removeIf(), etc. and it's not worth trying to
>> chase them all down.
> 
> Agreed. In fact that was the reason why I originally used "operations
> like...", but your suggested change above, to this text, I believe
> covers all these relevant APIs.
> 
>>
>>
>>> This method acts as bridge between array-based and collection-based
>>> APIs, in
>>> combination with {@link Collection#toArray}.
>>
>> This (from the original text) should actually be part of the @apiNote.
>> However, it was written before the @apiNote concept existed. So, start
>> the @apiNote before this text.
> 
> Done.
>>
>>> 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.
>> This UOE statement now redundant with the above.
>>
> This has now been removed in favour of the suggested change.
> 
>>
>> I do think it's reasonable to have examples here. Interestingly, the
>> original (pre-varargs) purpose of Arrays.asList() was to wrap an
>> existing array in a list. With varargs, this method is probably now
>> more often used to create a list from arguments. Both uses are valid,
>> but the first is now less obvious and so I think deserves a new
>> example. The latter remains valid even with List.of() and friends,
>> since those methods make a copy of the array that might not be
>> necessary in all cases.
>>
>> Here's what I'd suggest:
>>
>>  ?- add a simple (~2 line) example showing wrapping of an existing array
>>  ?? in a list
> Done. Added a new example to show this:
> 
>  ???? * <p>This method provides a way to wrap an existing array:
>  ???? * <pre>
>  ???? *???? Integer[] numbers = ...
>  ???? *???? ...
>  ???? *???? List&lt;Integer&gt; values = Arrays.asList(numbers);
>  ???? * </pre>
> 
> While adding this, I realized that the current javadoc doesn't mention
> anything about the behaviour of this method when a null array is passed
> to it. The implementation currently throws a NullPointerException. So I
> went ahead and updated the javadoc to include:
> 
>  ???? * @throws NullPointerException if the passed array is {@code null}
> 
> 
>>
>>  ?- restore the "Three Stooges" example (beginning with "This method
>> also provides...")
> 
> Done.
>>
>>  ?- add a note emphasizing that the returned list is NOT unmodifiable.
>> it's a common mistake to assume that it is. I'd also put in a
>> reference to List.html#unmodifiable here in case people do want an
>> unmodifiable list.
> 
> Done. I looked up the javadoc style guide[1] (is that still relevant,
> especially for contributions to the JDK itself?) and javadoc of some
> "recent" files within the JDK code, to see what's the current way to
> emphasize certain parts of the comments. I couldn't find anything
> conclusive, so I decided to use "<em>". Let me know if there's some
> other preferred way.
>>
>>>  ???? * @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
>>>  ???? * @see List#of()
>>
>> OK. We probably don't need the @see for List.of if there's a reference
>> to the "unmodifiable lists" section above.
> 
> Done. "@see List#of()" is now removed in this updated version. Bernd,
> let us know if you agree that this update to include reference to the
> List.html#unmodifiable covers the use case for which we introduced the
> List#of() reference.
>>
>>
>> I can sponsor this change for you. Since we're changing testable
>> assertions, this will also require a CSR request. I'll take care of
>> that for you too.
> Thank you :)
> 
> [1]
> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#styleguide
> 
> -Jaikiran
> 
-------------- next part --------------
# HG changeset patch
# User smarks
# Date 1535208403 -19800
#      Sat Aug 25 20:16:43 2018 +0530
# Node ID fbb71a7edc1aeeb6065e309a3efa67bc7ead6a3c
# Parent  9bf5205655ee3a8199abda638ad685b76a43a6fc
7033681: Arrays.asList methods needs better documentation
Reviewed-by: smarks
Contributed-by: jai.forums2013 at gmail.com

diff -r 9bf5205655ee src/java.base/share/classes/java/util/Arrays.java
--- a/src/java.base/share/classes/java/util/Arrays.java	Fri Sep 14 12:10:28 2018 -0400
+++ b/src/java.base/share/classes/java/util/Arrays.java	Wed Sep 19 10:31:21 2018 -0700
@@ -28,6 +28,7 @@
 import jdk.internal.HotSpotIntrinsicCandidate;
 import jdk.internal.util.ArraysSupport;
 
+import java.io.Serializable;
 import java.lang.reflect.Array;
 import java.util.concurrent.ForkJoinPool;
 import java.util.function.BinaryOperator;
@@ -4288,21 +4289,41 @@
     // 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}.
+     * Returns a fixed-size list backed by the specified array. Changes made to
+     * the array will be visible in the returned list, and changes made to the
+     * list will be visible in the array. The returned list is
+     * {@link Serializable} and implements {@link RandomAccess}.
+     *
+     * <p>The returned list implements the optional Collection methods, except those
+     * that would change the size of the returned list. Those methods leave
+     * the list unchanged and throw {@link UnsupportedOperationException}.
+     *
+     * @apiNote
+     * This method acts as bridge between array-based and collection-based
+     * APIs, in combination with {@link Collection#toArray}.
+     *
+     * <p>This method provides a way to wrap an existing array:
+     * <pre>{@code
+     *     Integer[] numbers = ...
+     *     ...
+     *     List<Integer> values = Arrays.asList(numbers);
+     * }</pre>
      *
      * <p>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>
+     * <pre>{@code
+     *     List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");
+     * }</pre>
+     *
+     * <p>The list returned by this method <em>is modifiable.</em>
+     * To create an unmodifiable list, see
+     * {@link Collections#unmodifiableList Collections.unmodifiableList}
+     * or <a href="List.html#unmodifiable">Unmodifiable Lists</a>.
      *
      * @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
+     * @throws NullPointerException if the specified array is {@code null}
      */
     @SafeVarargs
     @SuppressWarnings("varargs")

From jonathan.gibbons at oracle.com  Wed Sep 19 17:42:48 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Sep 2018 10:42:48 -0700
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: <5BA28A98.7070000@oracle.com>

Jaikiran,

Referring back to the original email discussion, changes like this may 
require a
CSR to be filed.

 From Stuart Marks:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
> 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.

-- Jon


On 08/20/2018 05:26 AM, 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 huizhe.wang at oracle.com  Wed Sep 19 18:48:30 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 19 Sep 2018 11:48:30 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
Message-ID: <5BA299FE.9090406@oracle.com>

Hi,

After much discussion and 10 iterations of reviews, this proposal has 
evolved from what was the original isSameContent method to a mismatch 
method. API-wise, a compare method was also considered as it looked like 
just a short step forward from mismatch, however, it was eventually 
dropped since there is no convincing use case comparing files 
lexicographically by contents. Impl-wise, extensive performance 
benchmarking has been done to compare a buffered reading vs memory 
mapping, the result was that a simple buffered reading performed better 
among small files, and those with the mismatched byte closer to the 
beginning of files. Since the proposed method's targeted files are small 
ones, the impl currently does a buffered reading only.

Please review.

JBS: https://bugs.openjdk.java.net/browse/JDK-8202285

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html

webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/

Thanks,
Joe


From roger.riggs at oracle.com  Wed Sep 19 19:18:22 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 19 Sep 2018 15:18:22 -0400
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
Message-ID: <c8472cf3-bacb-023f-4a5d-086b4c077404@oracle.com>

Hi Pallavi,

On 9/19/18 1:15 PM, Pallavi Sonal wrote:
> Hi,
>
> Please review the changes to the following issue:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>
>   
>
> The proposed fix is located at:
>
> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
DateTimeFormatterBuilder.java: 3463+

It would be cleaner and not create any new objects to write a private 
method that
compared a string with a subSequence.? And the if statement would also 
be more readable.

If the text CharSequence is shorter than 3 or 5 or 6, I think you'll see 
an unexpected index exception.
That check could be built into the private method.

Since the if ... then ... else identifies exactly what string is in the 
input, it could use
only appendLiteral (instead of the pattern and appendOffset).
Then only appendLiteral would be needed and there would be fewer 
variables and conditions
in lines 3459-3470.

3478: the extra local variable isn't necessary if the (offsetPresent) 
?... expression were used in-line.

Thanks, Roger
>
>   
>
> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>
>   
>
> [1] https://en.wikipedia.org/wiki/ISO_8601
>
>   
>
> Thanks,
>
> Pallavi Sonal
>
>   
>
>   


From naoto.sato at oracle.com  Wed Sep 19 20:04:59 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 19 Sep 2018 13:04:59 -0700
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
Message-ID: <41f3dfd5-9c9b-c492-fe0a-8c8035cc2a48@oracle.com>

Hi Pallavi,

Thank you for working on this. I think the javadoc should also be 
updated, mentioning offset parsing.

Naoto

On 9/19/18 10:15 AM, Pallavi Sonal wrote:
> Hi,
> 
> Please review the changes to the following issue:
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> 
>   
> 
> The proposed fix is located at:
> 
> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> 
>   
> 
> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> 
>   
> 
> [1] https://en.wikipedia.org/wiki/ISO_8601
> 
>   
> 
> Thanks,
> 
> Pallavi Sonal
> 
>   
> 
>   
> 

From jonathan.gibbons at oracle.com  Wed Sep 19 20:12:50 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Sep 2018 13:12:50 -0700
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
In-Reply-To: <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>
References: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
 <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>
 <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>
Message-ID: <5BA2ADC2.9070504@oracle.com>

It should really be "if n is less than or equal to zero" (equal, not equals)

-- Jon


On 09/19/2018 05:35 AM, Jim Laskey wrote:
> Thank you.  Updated.
>
>> On Sep 19, 2018, at 4:20 AM, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
>>
>> Hi Jim,
>>
>> I'm not native english speaker. But that does not seem to be right for me:
>>
>> 2983      * @throws IllegalArgumentException if n is less that equals to zero.
>>
>> 3029      * @throws IllegalArgumentException if n is less that equals to zero.
>>
>> I would write it as: if n is less than or equals to zero.
>>
>> Best regards,
>> Andrej Golovnin
>> On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey <james.laskey at oracle.com> wrote:
>>> Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>>>
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>>>
>>> Cheers,
>>>
>>> ? Jim
>>>


From Alan.Bateman at oracle.com  Wed Sep 19 20:14:58 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Sep 2018 21:14:58 +0100
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <5BA299FE.9090406@oracle.com>
References: <5BA299FE.9090406@oracle.com>
Message-ID: <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>

On 19/09/2018 19:48, Joe Wang wrote:
> Hi,
>
> After much discussion and 10 iterations of reviews, this proposal has 
> evolved from what was the original isSameContent method to a mismatch 
> method. API-wise, a compare method was also considered as it looked 
> like just a short step forward from mismatch, however, it was 
> eventually dropped since there is no convincing use case comparing 
> files lexicographically by contents. Impl-wise, extensive performance 
> benchmarking has been done to compare a buffered reading vs memory 
> mapping, the result was that a simple buffered reading performed 
> better among small files, and those with the mismatched byte closer to 
> the beginning of files. Since the proposed method's targeted files are 
> small ones, the impl currently does a buffered reading only.
>
> Please review.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
>
> specdiff: 
> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html
>
> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
Starting out using buffered I/O is probably okay but I assume we will 
want to change this in the future to having it use memory mapped I/O 
beyond a certain threshold.

Can you explain the use of toRealPath and comparing the names? That 
shouldn't be needed. Also the catching of ProviderMismatchExcepiton 
seems a bit strange too. Can you replace mismatchByAttrs with 
isSameFile? You could call this from Files.mismatch and then use the 
supporting implementation for the case that the files are not the same.

-Alan

From brian.burkhalter at oracle.com  Wed Sep 19 20:44:51 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Sep 2018 13:44:51 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
Message-ID: <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>

On Sep 19, 2018, at 1:14 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Starting out using buffered I/O is probably okay but I assume we will want to change this in the future to having it use memory mapped I/O beyond a certain threshold.

For the buffered case, could there be any performance advantage to using direct buffers with FileChannel and comparing running checksums of the two sources?

Brian

From brian.burkhalter at oracle.com  Wed Sep 19 20:52:51 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Sep 2018 13:52:51 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
Message-ID: <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com>

On Sep 19, 2018, at 1:44 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Sep 19, 2018, at 1:14 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> Starting out using buffered I/O is probably okay but I assume we will want to change this in the future to having it use memory mapped I/O beyond a certain threshold.
> 
> For the buffered case, could there be any performance advantage to using direct buffers with FileChannel and comparing running checksums of the two sources?

Don?t think this would work however as two files with differing content could conceivable have the same checksum however likely that might be.

Brian

From brian.burkhalter at oracle.com  Wed Sep 19 20:53:56 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Sep 2018 13:53:56 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
 <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com>
Message-ID: <566CEB7D-28FB-432A-9C91-7406DAD7768A@oracle.com>


On Sep 19, 2018, at 1:52 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

>> For the buffered case, could there be any performance advantage to using direct buffers with FileChannel and comparing running checksums of the two sources?
> 
> Don?t think this would work however as two files with differing content could conceivable have the same checksum however likely that might be.


s/conceivable /conceivably/.
s/likely/unlikely/.

Brian

From roger.riggs at oracle.com  Wed Sep 19 21:02:58 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 19 Sep 2018 17:02:58 -0400
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
Message-ID: <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>

Hi Alan,

On 9/19/18 4:14 PM, Alan Bateman wrote:
> On 19/09/2018 19:48, Joe Wang wrote:
>> Hi,
>>
>> After much discussion and 10 iterations of reviews, this proposal has 
>> evolved from what was the original isSameContent method to a mismatch 
>> method. API-wise, a compare method was also considered as it looked 
>> like just a short step forward from mismatch, however, it was 
>> eventually dropped since there is no convincing use case comparing 
>> files lexicographically by contents. Impl-wise, extensive performance 
>> benchmarking has been done to compare a buffered reading vs memory 
>> mapping, the result was that a simple buffered reading performed 
>> better among small files, and those with the mismatched byte closer 
>> to the beginning of files. Since the proposed method's targeted files 
>> are small ones, the impl currently does a buffered reading only.
>>
>> Please review.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
>>
>> specdiff: 
>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
> Starting out using buffered I/O is probably okay but I assume we will 
> want to change this in the future to having it use memory mapped I/O 
> beyond a certain threshold.
This came up in off-line discussions, it seems unlikely that two files 
will differ only in the last of 100Mb
and it will require a separate code path that will very infrequently be 
exercised.? So I'd still to a single
technique even if it is slightly slower for very large files to keep the 
size of the code in check.
If it shows up later as a performance problem it can be added.

$.02, Roger

>
> Can you explain the use of toRealPath and comparing the names? That 
> shouldn't be needed. Also the catching of ProviderMismatchExcepiton 
> seems a bit strange too. Can you replace mismatchByAttrs with 
> isSameFile? You could call this from Files.mismatch and then use the 
> supporting implementation for the case that the files are not the same.
>
> -Alan


From scolebourne at joda.org  Wed Sep 19 21:20:28 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 19 Sep 2018 22:20:28 +0100
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
Message-ID: <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>

Thanks for looking at this.

The proposed fix does not tackle the bug fully. The bug is that the spec says

"The format consists of: The ISO_OFFSET_DATE_TIME where ..."

As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.

In addition, the fix doesn't work properly. Parsers work off a
CharSequence which may be much longer than the instant. For example,
the instant might be followed by a literal space and then a ZoneId.
Using (length - 3) is simply not a valid approach - the parsing code
cannot use the length like that.

Furthermore, although there are numerous valid ISO-8601 ways of saying
zero, this format uses dashes and colons in the date/time part, so
ISO-8601 restricts the offset to only those formats that include
colons.

I think it simply needs the appendLiteral(Z) changing to appendOffsetId()
And line 3495 changes to use the offset from the newContext.

thanks
Stephen


On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Hi,
>
> Please review the changes to the following issue:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>
>
>
> The proposed fix is located at:
>
> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>
>
>
> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>
>
>
> [1] https://en.wikipedia.org/wiki/ISO_8601
>
>
>
> Thanks,
>
> Pallavi Sonal
>
>
>
>

From Sergey.Bylokhov at oracle.com  Wed Sep 19 21:25:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Sep 2018 14:25:41 -0700
Subject: <AWT Dev> RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
In-Reply-To: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
References: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
Message-ID: <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>

Looks fine.

On 19/09/2018 10:18, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>> 1188 lines changed: 252 ins; 591 del; 345 mod;
> 
> Hi all,
> 
> could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
> testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac
> 
> Thanks,
> -- Igor
> 


-- 
Best regards, Sergey.

From magnus.ihse.bursie at oracle.com  Wed Sep 19 21:30:24 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Sep 2018 23:30:24 +0200
Subject: RFR: JDK-8210924 Remove PACKAGE_PATH
Message-ID: <feffc8ee-010b-1f54-a4e1-eeaa37297aae@oracle.com>

The variable PACKAGE_PATH crept into the build when the macosx port was 
integrated. It is not used, however, and should be removed. (This is a 
BSD construct, and the macosx port was based on the BSD port.)

If/when the BSD port ever gets integrated upstream, we'll know better 
then how to restore PACKAGE_PATH on the proper places.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210924
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8210924-remove-PACKAGE_PATH/webrev.01

/Magnus


From igor.ignatyev at oracle.com  Wed Sep 19 21:37:47 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 19 Sep 2018 14:37:47 -0700
Subject: RFR(XS): 8210925 : move bytecode testlibrary to top-level testlibrary
Message-ID: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>

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

Hi all,

could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory?

webrev: http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8210925
testing: java/lang/invoke/condy tests

Thanks,
-- Igor

From stuart.marks at oracle.com  Wed Sep 19 22:21:18 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 19 Sep 2018 15:21:18 -0700
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
Message-ID: <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>



On 9/18/18 10:51 AM, Jim Laskey wrote:
> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
> csr: https://bugs.openjdk.java.net/browse/JDK-8202443

Hi Jim,

For citing the JLS, there's a @jls javadoc tag that you might want to use. There 
are a couple usages elsewhere in String.java already.

Is there going to be an escape() method that does the inverse of this? I thought 
that this was part of your original suite of string enhancements. Will this be 
proposed separately, or is it unnecessary?


2979      * Each unicode escape in the form \unnnn is translated to the
2980      * unicode character whose code point is {@code 0xnnnn}. Care should be
2981      * taken when using UTF-16 surrogate pairs to ensure that the high
2982      * surrogate (U+D800..U+DBFF) is immediately followed by a low surrogate
2983      * (U+DC00..U+DFFF) otherwise a
2984      * {@link java.nio.charset.CharacterCodingException} may occur during UTF-8
2985      * decoding.


I know you're going to update this based on Naoto's comments, but I'd suggest 
rethinking this section. The \unnnn construct is called a "Unicode escape" per 
JLS 3.3, but how it's handled has little to do with Unicode. The nnnn digits are 
simply translated into a 16-bit 'char' value. Any such value will work, even if 
it's an invalid UTF-16 code unit (such as 0xFFF0) or an unpaired surrogate.

I believe this is consistent with the JLS treatment of \unnnn.

It might be sufficient to say that \unnnn is translated into a 16-bit 'char' 
value, and leave it at that.

s'marks

From stuart.marks at oracle.com  Wed Sep 19 22:23:04 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 19 Sep 2018 15:23:04 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <5BA28A98.7070000@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <5BA28A98.7070000@oracle.com>
Message-ID: <e56ea5dc-45c0-807e-428a-9a31fac24827@oracle.com>

Hi Jon,

Yes, definitely, given the scope of the current proposed changes, I intend to 
file a CSR for this changeset on Jaikiran's behalf.

s'marks

On 9/19/18 10:42 AM, Jonathan Gibbons wrote:
> Jaikiran,
> 
> Referring back to the original email discussion, changes like this may require a
> CSR to be filed.
> 
>  From Stuart Marks:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
>> 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.
> 
> -- Jon
> 
> 
> On 08/20/2018 05:26 AM, 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 mandy.chung at oracle.com  Wed Sep 19 22:32:50 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 19 Sep 2018 15:32:50 -0700
Subject: RFR(XS): 8210925 : move bytecode testlibrary to top-level
 testlibrary
In-Reply-To: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
References: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
Message-ID: <b6a99965-d873-5ad9-a7ae-4f4d79a6aaea@oracle.com>

Hi Igor,

Are you planning to convert the hotspot tests to use this bytecode library?

This bytecode library is one version that was snapshot when these condy 
tests
were integrated in JDK.?? It has likely been evolved.?? Maurizio and 
Robert may
comment on this whether this bytecode library is ready to open for more 
tests
to use.? When the bytecode library is updated to a newer version.

Mandy

On 9/19/18 2:37 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
>> 14 lines changed: 0 ins; 0 del; 14 mod;
> Hi all,
>
> could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory?
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210925
> testing: java/lang/invoke/condy tests
>
> Thanks,
> -- Igor


From jonathan.gibbons at oracle.com  Wed Sep 19 22:43:43 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Sep 2018 15:43:43 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <e56ea5dc-45c0-807e-428a-9a31fac24827@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <5BA28A98.7070000@oracle.com>
 <e56ea5dc-45c0-807e-428a-9a31fac24827@oracle.com>
Message-ID: <5BA2D11F.60703@oracle.com>

Stuart,

OK, I didn't know you already had that in mind.

-- Jon

On 09/19/2018 03:23 PM, Stuart Marks wrote:
> Hi Jon,
>
> Yes, definitely, given the scope of the current proposed changes, I 
> intend to file a CSR for this changeset on Jaikiran's behalf.
>
> s'marks
>
> On 9/19/18 10:42 AM, Jonathan Gibbons wrote:
>> Jaikiran,
>>
>> Referring back to the original email discussion, changes like this 
>> may require a
>> CSR to be filed.
>>
>>  From Stuart Marks:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html 
>>
>>> 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.
>>
>> -- Jon
>>
>>
>> On 08/20/2018 05:26 AM, 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 igor.ignatyev at oracle.com  Wed Sep 19 22:54:00 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 19 Sep 2018 15:54:00 -0700
Subject: RFR(XS): 8210925 : move bytecode testlibrary to top-level
 testlibrary
In-Reply-To: <b6a99965-d873-5ad9-a7ae-4f4d79a6aaea@oracle.com>
References: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
 <b6a99965-d873-5ad9-a7ae-4f4d79a6aaea@oracle.com>
Message-ID: <5661A4B8-43B9-40BB-B9EB-6C09E8CE2E41@oracle.com>

Hi Mandy,

yes, eventually I'd like to see this library being used in place of ASM in our tests. I ain't planning to do it in JDK 12 TF though.

if there is a newer version ready, I'm happy to update (and test) the library, although it shouldn't block testlibraries "merge" activity.

-- Igor

> On Sep 19, 2018, at 3:32 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> Hi Igor,
> 
> Are you planning to convert the hotspot tests to use this bytecode library?
> 
> This bytecode library is one version that was snapshot when these condy tests 
> were integrated in JDK.   It has likely been evolved.   Maurizio and Robert may 
> comment on this whether this bytecode library is ready to open for more tests 
> to use.  When the bytecode library is updated to a newer version.
> 
> Mandy
> 
> On 9/19/18 2:37 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html>
>>> 14 lines changed: 0 ins; 0 del; 14 mod;
>> Hi all,
>> 
>> could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory?
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210925 <https://bugs.openjdk.java.net/browse/JDK-8210925>
>> testing: java/lang/invoke/condy tests
>> 
>> Thanks,
>> -- Igor
> 


From huizhe.wang at oracle.com  Thu Sep 20 00:34:10 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 19 Sep 2018 17:34:10 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
Message-ID: <5BA2EB02.7030204@oracle.com>



On 9/19/18, 2:02 PM, Roger Riggs wrote:
> Hi Alan,
>
> On 9/19/18 4:14 PM, Alan Bateman wrote:
>> On 19/09/2018 19:48, Joe Wang wrote:
>>> Hi,
>>>
>>> After much discussion and 10 iterations of reviews, this proposal 
>>> has evolved from what was the original isSameContent method to a 
>>> mismatch method. API-wise, a compare method was also considered as 
>>> it looked like just a short step forward from mismatch, however, it 
>>> was eventually dropped since there is no convincing use case 
>>> comparing files lexicographically by contents. Impl-wise, extensive 
>>> performance benchmarking has been done to compare a buffered reading 
>>> vs memory mapping, the result was that a simple buffered reading 
>>> performed better among small files, and those with the mismatched 
>>> byte closer to the beginning of files. Since the proposed method's 
>>> targeted files are small ones, the impl currently does a buffered 
>>> reading only.
>>>
>>> Please review.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
>>>
>>> specdiff: 
>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html
>>>
>>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
>> Starting out using buffered I/O is probably okay but I assume we will 
>> want to change this in the future to having it use memory mapped I/O 
>> beyond a certain threshold.
> This came up in off-line discussions, it seems unlikely that two files 
> will differ only in the last of 100Mb
> and it will require a separate code path that will very infrequently 
> be exercised.  So I'd still to a single
> technique even if it is slightly slower for very large files to keep 
> the size of the code in check.
> If it shows up later as a performance problem it can be added.

+1
>
> $.02, Roger
>
>>
>> Can you explain the use of toRealPath and comparing the names? That 
>> shouldn't be needed. Also the catching of ProviderMismatchExcepiton 
>> seems a bit strange too. Can you replace mismatchByAttrs with 
>> isSameFile? You could call this from Files.mismatch and then use the 
>> supporting implementation for the case that the files are not the same.

The purpose of toRealPath is so that we can do a quick Path comparison 
by following symlinks if any, I'll add a test to compare a file and its 
symbolic link. ProviderMismatchExcepiton was added in one of the 
iterations when we defined UOE, shall be removed in the next update 
(I'll have an update after some performance work to compare with direct 
buffer is done).

mismatchByAttrs cannot be replaced with isSameFile, it does one edge 
case check more than isSameFile when the size of one of the files is 
zero. mismatchByAttrs opens the files once vs twice if isSameFile and 
size(path) are called.

Thanks,
Joe

>>
>> -Alan
>

From huizhe.wang at oracle.com  Thu Sep 20 00:59:40 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 19 Sep 2018 17:59:40 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
 <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com>
Message-ID: <5BA2F0FC.90102@oracle.com>



On 9/19/18, 1:52 PM, Brian Burkhalter wrote:
> On Sep 19, 2018, at 1:44 PM, Brian Burkhalter<brian.burkhalter at oracle.com>  wrote:
>
>> On Sep 19, 2018, at 1:14 PM, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>>
>>> Starting out using buffered I/O is probably okay but I assume we will want to change this in the future to having it use memory mapped I/O beyond a certain threshold.
>> For the buffered case, could there be any performance advantage to using direct buffers with FileChannel and comparing running checksums of the two sources?
> Don?t think this would work however as two files with differing content could conceivable have the same checksum however likely that might be.

I'll do some performance testing for both cases, FileChannel/direct 
buffer and possible checksum comparison, although, as you said, the 
later might not work since we need to be 100%. The probability of false 
positives is likely extremely low, but is not zero after all. I'll do 
the performance check any ways just out of curiosity. But in many cases, 
checksum comparison may not be faster than direct comparison, esp. in 
this case the API compares just two files. Checksum values would be nice 
if there are multiple files to compare.

Thanks,
Joe

>
> Brian

From jai.forums2013 at gmail.com  Thu Sep 20 02:46:04 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 20 Sep 2018 08:16:04 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
Message-ID: <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>

Hello Stuart,


On 19/09/18 11:06 PM, Stuart Marks wrote:
> ?
>
>> While adding this, I realized that the current javadoc doesn't mention
>> anything about the behaviour of this method when a null array is passed
>> to it. The implementation currently throws a NullPointerException. So I
>> went ahead and updated the javadoc to include:
>>
>> ???? * @throws NullPointerException if the passed array is {@code null}
>
> Strictly speaking this isn't necessary, as the class doc has the
> following statement:
>
>> ?* <p>The methods in this class all throw a {@code
>> NullPointerException},
>> ?* if the specified array reference is null, except where noted.
>

I hadn't noticed that :)
>
>
> **
>
> The patch you sent is pretty good as it stands, but there were a
> couple minor things that I think could still be improved. In the
> interest of time, instead of asking you to make the changes, I went
> ahead and modified the patch myself. The modifications are as follows:
>
> -???? * <p>The returned list can be changed only in certain ways.
> Operations
> -???? * that would change the size of the returned list leave the list
> unchanged
> -???? * and throw {@link UnsupportedOperationException}.
>
> The first sentence didn't seem right to me, as it's quite vague. After
> some thought it finally occurred to me that what's necessary is a
> statement about the optional methods of the Collection interface. I've
> edited this paragraph thus:
>
> +???? * <p>The returned list implements the optional Collection
> methods, except those
> +???? * that would change the size of the returned list. Those methods
> leave
> +???? * the list unchanged and throw {@link
> UnsupportedOperationException}.

This looks fine to me.
>
> In the last paragraph I inverted the sense of "not unmodifiable" and
> added a link to the Collections.unmodifiableList method.
>
> +???? * <p>The list returned by this method <em>is modifiable.</em>
> +???? * To create an unmodifiable list, see
> +???? * {@link Collections#unmodifiableList Collections.unmodifiableList}
> +???? * or <a href="List.html#unmodifiable">Unmodifiable Lists</a>.
This change too looks good.

>
>
> I've changed the <pre></pre> code samples to use <pre>{@code
> ...}</pre>. This allows use of < and > instead of HTML entities &lt;
> and &gt;.
Thank you, I'll keep that in mind for any future changes like this.
>
> Finally, I had to change the changeset metadata to conform to the
> OpenJDK rules. Specifically, the changeset author is required to be an
> OpenJDK user name. Since you don't have one, I've listed your email
> address in the Contributed-by line of the changeset comment.
Thank you. More of a FYI and if it matters from a process point of view
- in a couple of my earlier contributions, the sponsors have used the
"Contributed-by" line to be "Jaikiran Pai <jaikiran.pai at gmail.com>" like
here http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07. I don't have
any specific preference on which one is used.

>
> I've attached the modified patch. If you're ok with it, I'll proceed
> with filing a CSR.
I re-read the whole javadoc contained in your modified patch and it all
looks good to me. Thank you very much for the help in sponsoring,
reviewing and providing detailed inputs during the review.

-Jaikiran


From Alan.Bateman at oracle.com  Thu Sep 20 07:07:40 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Sep 2018 08:07:40 +0100
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <5BA2EB02.7030204@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
 <5BA2EB02.7030204@oracle.com>
Message-ID: <71b38ab1-8728-e72c-c757-e0e1128bc9ac@oracle.com>

On 20/09/2018 01:34, Joe Wang wrote:
> :
>
> The purpose of toRealPath is so that we can do a quick Path comparison 
> by following symlinks if any, I'll add a test to compare a file and 
> its symbolic link. 
You don't need it. If two non-equals paths locate the same file then 
mismatch will do the right thing. By dropping it then you avoid a 
potentially expensive realpath (x2).


> ProviderMismatchExcepiton was added in one of the iterations when we 
> defined UOE, shall be removed in the next update (I'll have an update 
> after some performance work to compare with direct buffer is done).
Good.

>
> mismatchByAttrs cannot be replaced with isSameFile, it does one edge 
> case check more than isSameFile when the size of one of the files is 
> zero. mismatchByAttrs opens the files once vs twice if isSameFile and 
> size(path) are called.
Hmm, I think we make this a lot simpler.

-Alan

From Alan.Bateman at oracle.com  Thu Sep 20 07:12:34 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Sep 2018 08:12:34 +0100
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
Message-ID: <c317c245-bfd7-6858-ff40-157dac68c8af@oracle.com>

On 19/09/2018 22:02, Roger Riggs wrote:
> This came up in off-line discussions, it seems unlikely that two files 
> will differ only in the last of 100Mb
> and it will require a separate code path that will very infrequently 
> be exercised.? So I'd still to a single
> technique even if it is slightly slower for very large files to keep 
> the size of the code in check.
> If it shows up later as a performance problem it can be added.
>
I think this will eventually have a different implementation for the 
default file system where it can used memory mapping of file files. If 
the first 1MB of large files are identical then that it might switch 
over to mapping by chunk to compare the rest of the file. Starting out 
with a basic implementation is okay of course.

-Alan.


From vyom.tewari at oracle.com  Thu Sep 20 08:55:35 2018
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 20 Sep 2018 14:25:35 +0530
Subject: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/
In-Reply-To: <ABDC8250-9ADB-4ACA-8041-EEF68AB96434@oracle.com>
References: <ABDC8250-9ADB-4ACA-8041-EEF68AB96434@oracle.com>
Message-ID: <e9db88f6-d812-31dc-d844-0373d338e45a@oracle.com>

Hi Chris,

tests? looks good to me.

Thanks,



On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote:
> Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ in OpenJDK, thanks
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8210339
> webrev: http://cr.openjdk.java.net/~xyin/8210339/webrev.00/
>
> Regards,
> Chris


From xu.y.yin at oracle.com  Thu Sep 20 09:17:19 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 20 Sep 2018 17:17:19 +0800
Subject: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/
In-Reply-To: <e9db88f6-d812-31dc-d844-0373d338e45a@oracle.com>
References: <ABDC8250-9ADB-4ACA-8041-EEF68AB96434@oracle.com>
 <e9db88f6-d812-31dc-d844-0373d338e45a@oracle.com>
Message-ID: <29B034FA-D23D-487C-8A45-919D260F1F39@oracle.com>

Thank you, Vyom

Regards,
Chris

> On 20 Sep 2018, at 4:55 PM, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> tests  looks good to me.
> 
> Thanks,
> 
> 
> 
> On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote:
>> Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ in OpenJDK, thanks
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8210339
>> webrev: http://cr.openjdk.java.net/~xyin/8210339/webrev.00/
>> 
>> Regards,
>> Chris
> 


From xu.y.yin at oracle.com  Thu Sep 20 09:30:01 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 20 Sep 2018 17:30:01 +0800
Subject: [12] RFR 8199931:
 java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with
 "incorrect data received"
Message-ID: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>

Please review below minor change for 8199931, thanks

A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call ?new MulticastSocket(0)? to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.

bug: https://bugs.openjdk.java.net/browse/JDK-8199931

changes:

diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
--- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
+++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
@@ -40,6 +40,7 @@
 import java.net.DatagramSocket;
 import java.net.DatagramSocketImpl;
 import java.net.InetAddress;
+import java.net.InetSocketAddress;
 import java.net.MulticastSocket;
 import java.net.UnknownHostException;
 import java.nio.file.Files;
@@ -119,7 +120,10 @@
         Thread thr = new Thread(svr);
         thr.start();
 
-        MulticastSocket client = new MulticastSocket(0);
+        MulticastSocket client = new MulticastSocket(null);
+        // prevent MulticastSocket reuse previous address, see 8199931
+        client.setReuseAddress(false);
+        client.bind(new InetSocketAddress(0));
         client.connect(svr.getHost(), svr.getPort());
         pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
         extractRefs(client, "clientMulticastSocket?);

Regards,
Chris

From daniel.fuchs at oracle.com  Thu Sep 20 09:36:58 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 20 Sep 2018 10:36:58 +0100
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <5BA299FE.9090406@oracle.com>
References: <5BA299FE.9090406@oracle.com>
Message-ID: <607b37c4-2fe5-e426-e9d6-ecb0bb415168@oracle.com>

Hi Joe,

The spec reads very well to me.

On the implementation side:

  114             } else if (nRead1 != nRead2) {
  115                 int len = Math.min(nRead1, nRead2);
  116                 // there's always a mismatch when nRead1 != nRead2
  117                 return totalRead +
  118                     Arrays.mismatch(buffer1, 0, len, buffer2, 0, len);

I believe line 115 is not needed, and line 118 should be:

     Arrays.mismatch(buffer1, 0, nRead1, buffer2, 0, nRead2);

otherwise - if I'm not mistaken - there's the chance that

     Arrays.mismatch(buffer1, 0, len, buffer2, 0, len);

will return -1. Or am I missing something?

If I'm right then your test is probably missing a case
to explicitely test for that. Alternatively you could add a whitebox
test to test FilesMismatch.mismatch(InputStream, InputStream)
directly.

best regards,

-- daniel


On 19/09/2018 19:48, Joe Wang wrote:
> Hi,
> 
> After much discussion and 10 iterations of reviews, this proposal has 
> evolved from what was the original isSameContent method to a mismatch 
> method. API-wise, a compare method was also considered as it looked like 
> just a short step forward from mismatch, however, it was eventually 
> dropped since there is no convincing use case comparing files 
> lexicographically by contents. Impl-wise, extensive performance 
> benchmarking has been done to compare a buffered reading vs memory 
> mapping, the result was that a simple buffered reading performed better 
> among small files, and those with the mismatched byte closer to the 
> beginning of files. Since the proposed method's targeted files are small 
> ones, the impl currently does a buffered reading only.
> 
> Please review.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
> 
> specdiff: 
> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html 
> 
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
> 
> Thanks,
> Joe
> 


From chris.hegarty at oracle.com  Thu Sep 20 10:45:57 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 20 Sep 2018 11:45:57 +0100
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>
Message-ID: <3E71B442-6EEA-4258-9776-723007B1727F@oracle.com>


> On 19 Sep 2018, at 23:21, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> ...
> 
> 2979      * Each unicode escape in the form \unnnn is translated to the
> 2980      * unicode character whose code point is {@code 0xnnnn}. Care should be
> 2981      * taken when using UTF-16 surrogate pairs to ensure that the high
> 2982      * surrogate (U+D800..U+DBFF) is immediately followed by a low surrogate
> 2983      * (U+DC00..U+DFFF) otherwise a
> 2984      * {@link java.nio.charset.CharacterCodingException} may occur during UTF-8
> 2985      * decoding.
> 
> 
> I know you're going to update this based on Naoto's comments, but I'd suggest rethinking this section. The \unnnn construct is called a "Unicode escape" per JLS 3.3, but how it's handled has little to do with Unicode. The nnnn digits are simply translated into a 16-bit 'char' value. Any such value will work, even if it's an invalid UTF-16 code unit (such as 0xFFF0) or an unpaired surrogate.

I had a similar comment/question. CCE is a checked exception, and
since the method does not declare that it throws CCE, I took a look
at the implementation and came to the same conclusion as Stuart.

Additionally, why should non-character code points, like \uFFFE, be
translated? If it?s a non-character code point or a malformed surrogate
pair, would it not be better to just leave it as-is?

-Chris.

From xu.y.yin at oracle.com  Thu Sep 20 10:50:33 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Thu, 20 Sep 2018 18:50:33 +0800
Subject: [12] RFR 8199931:
 java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with
 "incorrect data received"
In-Reply-To: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>
References: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>
Message-ID: <90667FDA-B316-4E26-B633-C60BD55E4EF4@oracle.com>

Loop net-dev since the test is under java/net, thanks

> On 20 Sep 2018, at 5:30 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Please review below minor change for 8199931, thanks
> 
> A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call ?new MulticastSocket(0)? to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8199931
> 
> changes:
> 
> diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
> @@ -40,6 +40,7 @@
> import java.net.DatagramSocket;
> import java.net.DatagramSocketImpl;
> import java.net.InetAddress;
> +import java.net.InetSocketAddress;
> import java.net.MulticastSocket;
> import java.net.UnknownHostException;
> import java.nio.file.Files;
> @@ -119,7 +120,10 @@
>         Thread thr = new Thread(svr);
>         thr.start();
> 
> -        MulticastSocket client = new MulticastSocket(0);
> +        MulticastSocket client = new MulticastSocket(null);
> +        // prevent MulticastSocket reuse previous address, see 8199931
> +        client.setReuseAddress(false);
> +        client.bind(new InetSocketAddress(0));
>         client.connect(svr.getHost(), svr.getPort());
>         pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>         extractRefs(client, "clientMulticastSocket?);
> 
> Regards,
> Chris


From chris.hegarty at oracle.com  Thu Sep 20 11:11:49 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 20 Sep 2018 12:11:49 +0100
Subject: [12] RFR 8199931:
 java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with
 "incorrect data received"
In-Reply-To: <90667FDA-B316-4E26-B633-C60BD55E4EF4@oracle.com>
References: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>
 <90667FDA-B316-4E26-B633-C60BD55E4EF4@oracle.com>
Message-ID: <D7789806-F2CA-49A6-B245-AC9450C11021@oracle.com>

Thank you for looking at this issue Chris Y.

I don?t disagree with the changes, but if you want to confirm your
suspicion, that the same port is being reused, then printing out
the client?s bound port would do that ( since the servers port is
already printed in the logs ). 

If such a change was integrated, then the next observed failure
would confirm or disconfirm your suspicion.

-Chris H.

> On 20 Sep 2018, at 11:50, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Loop net-dev since the test is under java/net, thanks
> 
>> On 20 Sep 2018, at 5:30 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>> 
>> Please review below minor change for 8199931, thanks
>> 
>> A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call ?new MulticastSocket(0)? to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8199931
>> 
>> changes:
>> 
>> diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
>> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
>> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
>> @@ -40,6 +40,7 @@
>> import java.net.DatagramSocket;
>> import java.net.DatagramSocketImpl;
>> import java.net.InetAddress;
>> +import java.net.InetSocketAddress;
>> import java.net.MulticastSocket;
>> import java.net.UnknownHostException;
>> import java.nio.file.Files;
>> @@ -119,7 +120,10 @@
>>        Thread thr = new Thread(svr);
>>        thr.start();
>> 
>> -        MulticastSocket client = new MulticastSocket(0);
>> +        MulticastSocket client = new MulticastSocket(null);
>> +        // prevent MulticastSocket reuse previous address, see 8199931
>> +        client.setReuseAddress(false);
>> +        client.bind(new InetSocketAddress(0));
>>        client.connect(svr.getHost(), svr.getPort());
>>        pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>>        extractRefs(client, "clientMulticastSocket?);
>> 
>> Regards,
>> Chris
> 


From james.laskey at oracle.com  Thu Sep 20 12:50:19 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Sep 2018 09:50:19 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>
Message-ID: <56EA6AA9-5546-4748-ADE4-755A9745DB3F@oracle.com>



> On Sep 19, 2018, at 7:21 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 
> 
> On 9/18/18 10:51 AM, Jim Laskey wrote:
>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
> 
> Hi Jim,
> 
> For citing the JLS, there's a @jls javadoc tag that you might want to use. There are a couple usages elsewhere in String.java already.

Will add.

> 
> Is there going to be an escape() method that does the inverse of this? I thought that this was part of your original suite of string enhancements. Will this be proposed separately, or is it unnecessary?

The general feeling is that it is unnecessary. The inverse method is also fraught with danger; too many decision points on various characters. Ex.does ?\r? translate to ?\r? or '\013? or `\u000D`, does ?\0? translate to ?\0? or?\u0000?.

> 
> 
> 2979      * Each unicode escape in the form \unnnn is translated to the
> 2980      * unicode character whose code point is {@code 0xnnnn}. Care should be
> 2981      * taken when using UTF-16 surrogate pairs to ensure that the high
> 2982      * surrogate (U+D800..U+DBFF) is immediately followed by a low surrogate
> 2983      * (U+DC00..U+DFFF) otherwise a
> 2984      * {@link java.nio.charset.CharacterCodingException} may occur during UTF-8
> 2985      * decoding.
> 
> 
> I know you're going to update this based on Naoto's comments, but I'd suggest rethinking this section. The \unnnn construct is called a "Unicode escape" per JLS 3.3, but how it's handled has little to do with Unicode. The nnnn digits are simply translated into a 16-bit 'char' value. Any such value will work, even if it's an invalid UTF-16 code unit (such as 0xFFF0) or an unpaired surrogate.
> 
> I believe this is consistent with the JLS treatment of \unnnn.
> 
> It might be sufficient to say that \unnnn is translated into a 16-bit 'char' value, and leave it at that.

Sure.

> 
> s'marks


From james.laskey at oracle.com  Thu Sep 20 12:52:08 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Sep 2018 09:52:08 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <3E71B442-6EEA-4258-9776-723007B1727F@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <a027255e-6032-7d44-7dcc-8612ce314f9e@oracle.com>
 <3E71B442-6EEA-4258-9776-723007B1727F@oracle.com>
Message-ID: <9CACA5E0-3037-4E72-AB52-9582DDE81B82@oracle.com>

Modified as per Stuart's suggestion.

> On Sep 20, 2018, at 7:45 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 19 Sep 2018, at 23:21, Stuart Marks <stuart.marks at oracle.com> wrote:
>> 
>> ...
>> 
>> 2979      * Each unicode escape in the form \unnnn is translated to the
>> 2980      * unicode character whose code point is {@code 0xnnnn}. Care should be
>> 2981      * taken when using UTF-16 surrogate pairs to ensure that the high
>> 2982      * surrogate (U+D800..U+DBFF) is immediately followed by a low surrogate
>> 2983      * (U+DC00..U+DFFF) otherwise a
>> 2984      * {@link java.nio.charset.CharacterCodingException} may occur during UTF-8
>> 2985      * decoding.
>> 
>> 
>> I know you're going to update this based on Naoto's comments, but I'd suggest rethinking this section. The \unnnn construct is called a "Unicode escape" per JLS 3.3, but how it's handled has little to do with Unicode. The nnnn digits are simply translated into a 16-bit 'char' value. Any such value will work, even if it's an invalid UTF-16 code unit (such as 0xFFF0) or an unpaired surrogate.
> 
> I had a similar comment/question. CCE is a checked exception, and
> since the method does not declare that it throws CCE, I took a look
> at the implementation and came to the same conclusion as Stuart.
> 
> Additionally, why should non-character code points, like \uFFFE, be
> translated? If it?s a non-character code point or a malformed surrogate
> pair, would it not be better to just leave it as-is?
> 
> -Chris.


From james.laskey at oracle.com  Thu Sep 20 12:53:26 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Sep 2018 09:53:26 -0300
Subject: RFR - JDK-8210717 String::detab, String::entab (Code Review)
In-Reply-To: <5BA2ADC2.9070504@oracle.com>
References: <7ABE2C29-DEC7-4C39-8B64-60F567BAE19F@oracle.com>
 <CAM6ZMz-EDmSB_3j4q57271kbH4rG459BiCepDB6-3p8Z9NVRKg@mail.gmail.com>
 <A03BCF0E-A517-4EC3-83E6-4ECD1A8ECBF7@oracle.com>
 <5BA2ADC2.9070504@oracle.com>
Message-ID: <03CC5EFB-BA5E-4377-8334-7B8DA418F986@oracle.com>

Caught that. Thx.

> On Sep 19, 2018, at 5:12 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> It should really be "if n is less than or equal to zero" (equal, not equals)
> 
> -- Jon
> 
> 
> On 09/19/2018 05:35 AM, Jim Laskey wrote:
>> Thank you.  Updated.
>> 
>>> On Sep 19, 2018, at 4:20 AM, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> I'm not native english speaker. But that does not seem to be right for me:
>>> 
>>> 2983      * @throws IllegalArgumentException if n is less that equals to zero.
>>> 
>>> 3029      * @throws IllegalArgumentException if n is less that equals to zero.
>>> 
>>> I would write it as: if n is less than or equals to zero.
>>> 
>>> Best regards,
>>> Andrej Golovnin
>>> On Tue, Sep 18, 2018 at 7:53 PM Jim Laskey <james.laskey at oracle.com> wrote:
>>>> Please review the code for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs.
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8210717/webrev/index.html
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210717
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8210718
>>>> 
>>>> Cheers,
>>>> 
>>>> ? Jim
>>>> 
> 


From pallavi.sonal at oracle.com  Thu Sep 20 12:54:08 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Thu, 20 Sep 2018 05:54:08 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
Message-ID: <871fb443-47c9-4860-815a-5d2064118fbb@default>

Thanks Roger , Naoto and Stephen for the review and valuable inputs. 
Here is the updated webrev for review :
http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ 

Thanks,
Pallavi Sonal

-----Original Message-----
From: Stephen Colebourne <scolebourne at joda.org> 
Sent: Thursday, September 20, 2018 2:50 AM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks for looking at this.

The proposed fix does not tackle the bug fully. The bug is that the spec says

"The format consists of: The ISO_OFFSET_DATE_TIME where ..."

As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.

In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.

Furthermore, although there are numerous valid ISO-8601 ways of saying zero, this format uses dashes and colons in the date/time part, so
ISO-8601 restricts the offset to only those formats that include colons.

I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.

thanks
Stephen


On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Hi,
>
> Please review the changes to the following issue:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>
>
>
> The proposed fix is located at:
>
> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>
>
>
> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>
>
>
> [1] https://en.wikipedia.org/wiki/ISO_8601
>
>
>
> Thanks,
>
> Pallavi Sonal
>
>
>
>

From scolebourne at joda.org  Thu Sep 20 13:02:18 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 20 Sep 2018 14:02:18 +0100
Subject: RFR - JDK-8203703 String::transform (CSR Review)
In-Reply-To: <24F1353A-726E-4DF0-A3AE-F6C4D01BCCBB@oracle.com>
References: <DB0440CA-2140-4ABF-9FAF-60891B57C7CF@oracle.com>
 <CACzrW9B55krP+izNCnasgKcRR_H_hj21kAq6g2Da2ED2KQqEOg@mail.gmail.com>
 <24F1353A-726E-4DF0-A3AE-F6C4D01BCCBB@oracle.com>
Message-ID: <CACzrW9BqRUeSPmNKjng6YiL0NJSH-GCTr9KVSViY2PuB3qxCNw@mail.gmail.com>

On Wed, 19 Sep 2018 at 14:51, Jim Laskey <james.laskey at oracle.com> wrote:
>         HTMLDocument html = `
>                        <html>
>                            <body>
>                                <p>Hello World.</p>
>                            </body>
>                        </html>
>                   `.transform(HTMLDocument::parse);

I can't say I love that parse example, although I can see it having
some use. It does feel a bit like functional excess, and wouldn't be
nearly as pretty if the parser needed some other flags to be passed
in. I think I still favour just returning `String` and naming as
`with`.

Stephen

From scolebourne at joda.org  Thu Sep 20 13:07:54 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 20 Sep 2018 14:07:54 +0100
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <871fb443-47c9-4860-815a-5d2064118fbb@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
Message-ID: <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>

Thanks for the update.

The test case does not cover the situation of MAX/MIN instant and an
offset other than zero, where the offset makes the instant invalid.
eg. a negative offset at MAX or a positive offset at MIN.

The doc of appendInstant() in DateTimeFormatterBuilder should be
clarified to cover the fact that any OffsetId is parsed.

thanks
Stephen


On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> Here is the updated webrev for review :
> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>
> Thanks,
> Pallavi Sonal
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Thursday, September 20, 2018 2:50 AM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>
> Thanks for looking at this.
>
> The proposed fix does not tackle the bug fully. The bug is that the spec says
>
> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>
> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>
> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>
> Furthermore, although there are numerous valid ISO-8601 ways of saying zero, this format uses dashes and colons in the date/time part, so
> ISO-8601 restricts the offset to only those formats that include colons.
>
> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>
> thanks
> Stephen
>
>
> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Hi,
> >
> > Please review the changes to the following issue:
> >
> > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> >
> >
> >
> > The proposed fix is located at:
> >
> > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> >
> >
> >
> > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> >
> >
> >
> > [1] https://en.wikipedia.org/wiki/ISO_8601
> >
> >
> >
> > Thanks,
> >
> > Pallavi Sonal
> >
> >
> >
> >

From james.laskey at oracle.com  Thu Sep 20 13:46:24 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 20 Sep 2018 10:46:24 -0300
Subject: RFR - JDK-8202442 - String::unescape (Code Review)
In-Reply-To: <ABAC04BB-30FC-449F-9EFF-C16D36F53F9C@oracle.com>
References: <074025A7-CF45-4B18-BC59-95B339BF0CC1@oracle.com>
 <00ddb59e-96cf-1aa5-e78f-22088801acc1@oracle.com>
 <7CA20516-7A94-46B7-9D2E-8348705FEEB7@oracle.com>
 <5BA258E4.8060404@oracle.com>
 <B10339BE-2FDD-48D8-B99B-BE00F581BF73@oracle.com>
 <b0b31605-c1ca-71e4-482a-7a143ee52b60@oracle.com>
 <ABAC04BB-30FC-449F-9EFF-C16D36F53F9C@oracle.com>
Message-ID: <766A71C5-4B22-471C-9CEF-EE54E7673793@oracle.com>

revised webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-02/index.html

> On Sep 19, 2018, at 11:57 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Will do.
> 
> 
>> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons <Jonathan.Gibbons at oracle.com> wrote:
>> 
>> If you're making the change, then you might add a test case based on Jan's suggestion, testing
>> 
>>    "\u005ct".equals(`\u005ct`.unescape())
>> 
>> -- Jon
>> 
>> 
>> On 9/19/18 7:40 AM, Jim Laskey wrote:
>>> I see and good point.  I think Jon is correct.  If you are using the JLS as the basis of your argument, then you better damn well stick to the JLS.
>>> 
>>> I?ll make the changes.
>>> 
>>> Cheers,
>>> 
>>> ? Jim
>>> 
>>> 
>>>> On Sep 19, 2018, at 11:10 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>>>> 
>>>> I guess Jon's comment was that (per JLS) the outcome of unicode unescapes can then participate in the escape sequences in String literals. So, this:
>>>> "\u005ct"
>>>> 
>>>> is (as far as I know) a single character-literal (a tab), while it seems that
>>>> `\u005ct`.unescape()
>>>> 
>>>> is two characters:
>>>> \t
>>>> 
>>>> Not sure if that's an intent or not.
>>>> 
>>>> Jan
>>>> 
>>>> On 18.9.2018 20:55, Jim Laskey wrote:
>>>>> The intent, of course, is to offset the raw string literals non-translation of Unicode escapes and escape sequences. That is, have the multi-line cake and eat the escapes too.
>>>>> 
>>>>> So a developer could have
>>>>> 
>>>>> 	String s = `
>>>>>                   \t\tTitle
>>>>>                   \t\t\tbody
>>>>> 		   ...
>>>>> 
>>>>>                   `.align().escape();
>>>>> 
>>>>> to have tabs inserted in the string.
>>>>> 
>>>>> "\\" "\u005c\u005c" and `\` all translate to the same string. `\u005c` translates to "\\u005c?. `\u005c`.unescape() thustranslates to be the same as "\\?, "\u005c\u005c" and `\`.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> ? Jim
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 18, 2018, at 3:33 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>>>> 
>>>>>> Jim,
>>>>>> 
>>>>>> In JLS, and hence javac, Unicode escape handling happens early on at a low level, before string escape handling. This means that it is technically possible to write string escape sequences in terms of Unicode escapes.
>>>>>> 
>>>>>> I'm not suggesting you should do the same here, but you should be aware of the difference, compared to javac behavior.
>>>>>> 
>>>>>> -- Jon
>>>>>> 
>>>>>> 
>>>>>> On 9/18/18 10:51 AM, Jim Laskey wrote:
>>>>>>> Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes.
>>>>>>> 
>>>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html
>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8202442
>>>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8202443
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> ? Jim
>>>>>>> 
>> 
> 


From adinn at redhat.com  Thu Sep 20 14:20:02 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 20 Sep 2018 15:20:02 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
Message-ID: <84fa6c2e-6a6e-a59a-8dff-175f7e50240f@redhat.com>

Ping!

Could I please get a review of this latest version of the JEP?

This includes responses to all previous comments with changes made both
to the JEP and the draft implementation.

I would like to get this into JDK12 if at all possible

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

On 10/09/18 19:05, Alan Bateman wrote:
> On 20/08/2018 16:18, Andrew Dinn wrote:
>> 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/
>>
>>
> The updated JEP looks much better.
> 
> I realize we've been through several iterations on this but I'm now
> wondering if the MappedByteBuffer is the right API. As you've shown,
> it's straight forward to map a region of NVM and use the existing API,
> I'm just not sure if it's the right API. I think I'd like to see a few
> examples of how the API might be used. ByteBuffers aren't intended for
> use by concurrent threads and I just wonder if the examples might need
> that. I also wonder if there is a possible connection with work in
> Project Panama and whether it's worth exploring if its scopes and
> pointers could be used to backed by NVM. The Risks and Assumption
> section mentions the 2GB limit which is another reminder that the MBB
> API may not be the right API.
> 
> The 2-arg force method to msync a region make sense? although it might
> be more consistent for the second parameter to be the length than the
> end offset.
> 
> A detail for later is whether UOE might be more appropriate for
> implementations that do not support the XXX_PERSISTENT modes.
> 
> -Alan.
> 

From brian.burkhalter at oracle.com  Thu Sep 20 15:10:50 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 20 Sep 2018 08:10:50 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <5BA2F0FC.90102@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
 <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com> <5BA2F0FC.90102@oracle.com>
Message-ID: <628BAAA4-C583-473A-8396-310865E4FAC1@oracle.com>


On Sep 19, 2018, at 5:59 PM, Joe Wang <huizhe.wang at oracle.com> wrote:

> I'll do some performance testing for both cases, FileChannel/direct buffer and possible checksum comparison, although, as you said, the later might not work since we need to be 100%. The probability of false positives is likely extremely low, but is not zero after all. I'll do the performance check any ways just out of curiosity. But in many cases, checksum comparison may not be faster than direct comparison, esp. in this case the API compares just two files. Checksum values would be nice if there are multiple files to compare.

I doubt the checksum test is worthwhile. It might be useful however to try FileChannel and direct byte buffers combined with ByteBuffer.mismatch() [1].

Thanks,

Brian

[1] https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/nio/ByteBuffer.html#mismatch(java.nio.ByteBuffer)

From mandy.chung at oracle.com  Thu Sep 20 16:58:22 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 20 Sep 2018 09:58:22 -0700
Subject: RFR(XS): 8210925 : move bytecode testlibrary to top-level
 testlibrary
In-Reply-To: <5661A4B8-43B9-40BB-B9EB-6C09E8CE2E41@oracle.com>
References: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
 <b6a99965-d873-5ad9-a7ae-4f4d79a6aaea@oracle.com>
 <5661A4B8-43B9-40BB-B9EB-6C09E8CE2E41@oracle.com>
Message-ID: <31b21be5-b458-8326-e7df-820ec4af4c22@oracle.com>

As the bytecode library is evolving, I'd recommend to move
the bytecode library when we start using it in the hotspot
tests and update it with the latest version.

Mandy

On 9/19/18 3:54 PM, Igor Ignatyev wrote:
> Hi Mandy,
>
> yes, eventually I'd like to see this library being used in place of 
> ASM in our tests. I ain't planning to do it in JDK 12 TF though.
>
> if there is a newer version ready, I'm happy to update (and test) the 
> library, although it shouldn't block testlibraries "merge" activity.
>
> -- Igor
>
>> On Sep 19, 2018, at 3:32 PM, mandy chung <mandy.chung at oracle.com 
>> <mailto:mandy.chung at oracle.com>> wrote:
>>
>> Hi Igor,
>>
>> Are you planning to convert the hotspot tests to use this bytecode 
>> library?
>>
>> This bytecode library is one version that was snapshot when these 
>> condy tests
>> were integrated in JDK.?? It has likely been evolved. Maurizio and 
>> Robert may
>> comment on this whether this bytecode library is ready to open for 
>> more tests
>> to use.? When the bytecode library is updated to a newer version.
>>
>> Mandy
>>
>> On 9/19/18 2:37 PM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
>>>> 14 lines changed: 0 ins; 0 del; 14 mod;
>>> Hi all,
>>>
>>> could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory?
>>>
>>> webrev:http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8210925
>>> testing: java/lang/invoke/condy tests
>>>
>>> Thanks,
>>> -- Igor
>>
>


From huizhe.wang at oracle.com  Thu Sep 20 17:28:47 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 20 Sep 2018 10:28:47 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <71b38ab1-8728-e72c-c757-e0e1128bc9ac@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
 <5BA2EB02.7030204@oracle.com>
 <71b38ab1-8728-e72c-c757-e0e1128bc9ac@oracle.com>
Message-ID: <5BA3D8CF.7020907@oracle.com>



On 9/20/18, 12:07 AM, Alan Bateman wrote:
> On 20/09/2018 01:34, Joe Wang wrote:
>> :
>>
>> The purpose of toRealPath is so that we can do a quick Path 
>> comparison by following symlinks if any, I'll add a test to compare a 
>> file and its symbolic link. 
> You don't need it. If two non-equals paths locate the same file then 
> mismatch will do the right thing. By dropping it then you avoid a 
> potentially expensive realpath (x2).
>
>
>> ProviderMismatchExcepiton was added in one of the iterations when we 
>> defined UOE, shall be removed in the next update (I'll have an update 
>> after some performance work to compare with direct buffer is done).
> Good.
>
>>
>> mismatchByAttrs cannot be replaced with isSameFile, it does one edge 
>> case check more than isSameFile when the size of one of the files is 
>> zero. mismatchByAttrs opens the files once vs twice if isSameFile and 
>> size(path) are called.
> Hmm, I think we make this a lot simpler.

Ok, I'll call isSameFile instead, that would get rid of toRealPath too, 
to not let these edge case handling penalize the most, normal use cases. 
The other way around (a bit more cost to the edge cases) shall be fine.

Thanks,
Joe

>
> -Alan

From jonathan.halliday at redhat.com  Thu Sep 20 16:17:33 2018
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Thu, 20 Sep 2018 17:17:33 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
Message-ID: <e503c1df-c68c-b7a6-77c2-ea9ad36c6b30@redhat.com>


Hi Alan

I'm a middleware engineer (transaction engine, message queues, etc) and 
I evolved the current API design whilst making some of Red Hat's Jakarta 
EE stack work with persistent memory. It's a good fit for our needs 
because it pretty much matches they way we currently do off-heap and 
persistent storage, so porting existing code is a breeze. For anything 
that is a 'make this bunch of bytes persistent' use case there isn't 
really a complex API. We're not trying to pass data structures to and 
fro as we would when calling a richer C library. The serialization layer 
takes care of flattening all the structures to an opaque byte[] or 
ByteBuffer already. We just need to be able to reason about the 
persistence guarantees the same way we can with the existing sync() 
call. We already take care of the threading, since existing storage 
solutions wouldn't work without those safeguards anyhow. So, there are 
certainly some use cases for which the current API is a good fit, 
because those are the ones I designed it for, based on code that already 
uses and copes with the limitations of MappedByteBuffer.

However... There are cases where we may want to get further 
optimizations by eliding the serialization to byte[]/ByteBuffer and 
instead be able to access persistent memory *as objects*. That's a 
harder problem and may involve language integration rather than just API 
changes, for example being able to allocate an object whose state 
(primitive fields, perhaps also object pointers) is backed by an 
(optionally explicitly specified area) of pmem. It's definitely a more 
powerful model, but also a much bigger problem to chew on.

Some halfway solution in which we can use Java objects to point into 
specific areas of memory in a typesafe way (e.g. 'that pmem address 
should be considered an int') would seem to be something that Panama 
could overlap with, but it's a convenience layer that could also be 
modelled by putting higher level abstractions over the proposed low 
level API. Over time we may have e.g. PersistentLong in the same way 
that today we have AtomicLong, but it's something that could be tested 
out in a 3rd party library initially and then migrated into the standard 
library if it's shown to be useful.

Is the proposed API sufficient for all use cases? Probably not. But it's 
useful for some and, so far as I can tell, non-harmful to others. Under 
the new release model what we have now is useful in its own right and 
should ship sooner rather than later, with additional functionality 
following later in a modular, agile fashion? I don't really see 
sufficient advantage in holding this pending e.g. investigation of 
integration with Panama, though that's definitely an interesting avenue 
for future work.

Regards

Jonathan

On 10/09/2018 19:05, Alan Bateman wrote:
...
> I realize we've been through several iterations on this but I'm now 
> wondering if the MappedByteBuffer is the right API. As you've shown, 
> it's straight forward to map a region of NVM and use the existing API, 
> I'm just not sure if it's the right API. I think I'd like to see a few 
> examples of how the API might be used. ByteBuffers aren't intended for 
> use by concurrent threads and I just wonder if the examples might need 
> that. I also wonder if there is a possible connection with work in 
> Project Panama and whether it's worth exploring if its scopes and 
> pointers could be used to backed by NVM. The Risks and Assumption 
> section mentions the 2GB limit which is another reminder that the MBB 
> API may not be the right API.


-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From jonathan.gibbons at oracle.com  Thu Sep 20 17:39:49 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 20 Sep 2018 10:39:49 -0700
Subject: Source file launcher - Handling of pre-compiled classes of the
 source file
In-Reply-To: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com>
References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com>
 <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com>
 <ae1e2c94-12d4-ece7-0775-4c72318e95ea@gmail.com>
 <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com>
Message-ID: <5BA3DB65.4080909@oracle.com>

This is tracked as JDK-8210839
https://bugs.openjdk.java.net/browse/JDK-8210839

-- Jon

On 09/15/2018 10:04 AM, Jonathan Gibbons wrote:
> Jaikiran,
>
> This issue is on our radar; there is no need for any additional action
> on your part at this point.
>
> -- Jon
>
>
> On 9/14/18 7:50 PM, Jaikiran Pai wrote:
>> Hello Peter,
>>
>>
>> On 14/09/18 1:03 PM, Peter Levart wrote:
>>> The check for main class is performed after compilation (which
>>> actually produces the main class name).
>>>
>>> I think it would be possible to check for all classes compiled from
>>> the source file after compilation without to much complication. The
>>> compilation produces classes and stores them into a Map<String,
>>> byte[]>. The keySet() of that map is a Set of compiled class names.
>>> Each of them could be tested via .getResource() invoked upon the
>>> application class loader. The error could even point to the URL of the
>>> conflicting class file that way...
>>>
>> Thank you for moving this to the correct mailing list. Thanks for those
>> details about how it's done and what can be done to improve this. Should
>> I report this as an enhancement request at bugs.java.com? I don't have
>> access to the OpenJDK JIRA for creating this request there.
>>
>> -Jaikiran
>


From huizhe.wang at oracle.com  Thu Sep 20 18:04:05 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 20 Sep 2018 11:04:05 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <c317c245-bfd7-6858-ff40-157dac68c8af@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <faf303f3-e28d-1c60-5238-34eb31471ab4@oracle.com>
 <c317c245-bfd7-6858-ff40-157dac68c8af@oracle.com>
Message-ID: <5BA3E115.5090703@oracle.com>



On 9/20/18, 12:12 AM, Alan Bateman wrote:
> On 19/09/2018 22:02, Roger Riggs wrote:
>> This came up in off-line discussions, it seems unlikely that two 
>> files will differ only in the last of 100Mb
>> and it will require a separate code path that will very infrequently 
>> be exercised.  So I'd still to a single
>> technique even if it is slightly slower for very large files to keep 
>> the size of the code in check.
>> If it shows up later as a performance problem it can be added.
>>
> I think this will eventually have a different implementation for the 
> default file system where it can used memory mapping of file files. If 
> the first 1MB of large files are identical then that it might switch 
> over to mapping by chunk to compare the rest of the file. Starting out 
> with a basic implementation is okay of course.

Sounds good. Will keep the basic impl, probably use 
FileChannel/ByteBuffer as Brian suggested, and look forward to the more 
complicated version if we hear any complaints. For the majority of text 
files, the basic impl would be enough. For example, the largest file in 
java.nio is about 180K.

Thanks,
Joe
>
> -Alan.
>

From huizhe.wang at oracle.com  Thu Sep 20 18:06:03 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 20 Sep 2018 11:06:03 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <607b37c4-2fe5-e426-e9d6-ecb0bb415168@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <607b37c4-2fe5-e426-e9d6-ecb0bb415168@oracle.com>
Message-ID: <5BA3E18B.10402@oracle.com>

Hi Daniel,

You're right, line 115 is not needed. I'll add a couple of test cases to 
cover the route.

Best,
Joe

On 9/20/18, 2:36 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> The spec reads very well to me.
>
> On the implementation side:
>
>  114             } else if (nRead1 != nRead2) {
>  115                 int len = Math.min(nRead1, nRead2);
>  116                 // there's always a mismatch when nRead1 != nRead2
>  117                 return totalRead +
>  118                     Arrays.mismatch(buffer1, 0, len, buffer2, 0, 
> len);
>
> I believe line 115 is not needed, and line 118 should be:
>
>     Arrays.mismatch(buffer1, 0, nRead1, buffer2, 0, nRead2);
>
> otherwise - if I'm not mistaken - there's the chance that
>
>     Arrays.mismatch(buffer1, 0, len, buffer2, 0, len);
>
> will return -1. Or am I missing something?
>
> If I'm right then your test is probably missing a case
> to explicitely test for that. Alternatively you could add a whitebox
> test to test FilesMismatch.mismatch(InputStream, InputStream)
> directly.
>
> best regards,
>
> -- daniel
>
>
> On 19/09/2018 19:48, Joe Wang wrote:
>> Hi,
>>
>> After much discussion and 10 iterations of reviews, this proposal has 
>> evolved from what was the original isSameContent method to a mismatch 
>> method. API-wise, a compare method was also considered as it looked 
>> like just a short step forward from mismatch, however, it was 
>> eventually dropped since there is no convincing use case comparing 
>> files lexicographically by contents. Impl-wise, extensive performance 
>> benchmarking has been done to compare a buffered reading vs memory 
>> mapping, the result was that a simple buffered reading performed 
>> better among small files, and those with the mismatched byte closer 
>> to the beginning of files. Since the proposed method's targeted files 
>> are small ones, the impl currently does a buffered reading only.
>>
>> Please review.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285
>>
>> specdiff: 
>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html 
>>
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
>>
>> Thanks,
>> Joe
>>
>

From huizhe.wang at oracle.com  Thu Sep 20 18:08:07 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 20 Sep 2018 11:08:07 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <628BAAA4-C583-473A-8396-310865E4FAC1@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <3e2990a1-33d1-600f-011f-497a85d93652@oracle.com>
 <74CD5888-73FD-4169-BB6F-4536CE61F979@oracle.com>
 <1FF20FD7-DDC8-4246-B75E-2C2B5C4B4900@oracle.com> <5BA2F0FC.90102@oracle.com>
 <628BAAA4-C583-473A-8396-310865E4FAC1@oracle.com>
Message-ID: <5BA3E207.5060600@oracle.com>



On 9/20/18, 8:10 AM, Brian Burkhalter wrote:
>
> On Sep 19, 2018, at 5:59 PM, Joe Wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>> I'll do some performance testing for both cases, FileChannel/direct 
>> buffer and possible checksum comparison, although, as you said, the 
>> later might not work since we need to be 100%. The probability of 
>> false positives is likely extremely low, but is not zero after all. 
>> I'll do the performance check any ways just out of curiosity. But in 
>> many cases, checksum comparison may not be faster than direct 
>> comparison, esp. in this case the API compares just two files. 
>> Checksum values would be nice if there are multiple files to compare.
>
> I doubt the checksum test is worthwhile. It might be useful however to 
> try FileChannel and direct byte buffers combined with 
> ByteBuffer.mismatch() [1].

Ok, save the time not to run checksum testing :-)  Will do the later, 
actually, I'm almost sure it will be FileChannel/ByteBuffer (better than 
the buffered reading).

Thanks,
Joe

>
> Thanks,
>
> Brian
>
> [1] 
> https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/nio/ByteBuffer.html#mismatch(java.nio.ByteBuffer) 
> <https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/nio/ByteBuffer.html#mismatch%28java.nio.ByteBuffer%29>

From jonathan.gibbons at oracle.com  Thu Sep 20 19:08:46 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 20 Sep 2018 12:08:46 -0700
Subject: RFR: 8210275: Source Launcher should fail if --source is used without
 a source file
Message-ID: <5BA3F03E.7090204@oracle.com>

Please review a small fix to the source launcher that showed up as
the launcher sometimes ignoring the --source option and finding/running
a class on the class path.

The problem occurs when the classpath is set after the --source option,
causing LM_CLASS mode to override the setting of LM_SOURCE.

In addition, some of the error messages that may be reported by the
source launcher are improved to use "source file" instead of "file" as
an indication that source-file mode is being used.

JBS: https://bugs.openjdk.java.net/browse/JDK-8210275
Webrev: http://cr.openjdk.java.net/~jjg/8210275/webrev.00/index.html

-- Jon


From stuart.marks at oracle.com  Thu Sep 20 19:34:03 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 20 Sep 2018 12:34:03 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
 <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
Message-ID: <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>



On 9/19/18 7:46 PM, Jaikiran Pai wrote:
> Thank you. More of a FYI and if it matters from a process point of view
> - in a couple of my earlier contributions, the sponsors have used the
> "Contributed-by" line to be "Jaikiran Pai <jaikiran.pai at gmail.com>" like
> here http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07. I don't have
> any specific preference on which one is used.

I'm happy to change the Contributed-by line to anything you want. After all this 
represents YOU and it's recorded in the changeset history. It's probably good to 
be consistent. Unfortunately I see the following changesets in the history right 
now:

changeset:   51755:6c394ed56b07
user:        xuelei
date:        Fri Sep 14 20:30:28 2018 -0700
files:       src/java.base/share/classes/javax/net/ssl/X509ExtendedKeyManager.java
description:
8210785: Trivial typo fix in X509ExtendedKeyManager javadoc
Reviewed-by: xuelei
Contributed-by: Jaikiran Pai <jaikiran.pai at gmail.com>


changeset:   49926:b7c2996d690b
user:        chegar
date:        Mon Apr 30 16:13:30 2018 +0100
files:       src/java.base/share/classes/java/net/InetAddress.java 
test/jdk/java/net/InetAddress/GetLoopbackAddress.java
description:
8201545: InetAddress.getByName/getAllByName should clarify empty String behavior
Reviewed-by: chegar
Contributed-by: Jaikiran Pai <jai.forums2013 at gmail.com>


Since you mentioned it I'll proceed with "Jaikiran Pai <jaikiran.pai at gmail.com>" 
since that looks a bit more "official". But do let me know if you have a 
different preference.

> I re-read the whole javadoc contained in your modified patch and it all
> looks good to me. Thank you very much for the help in sponsoring,
> reviewing and providing detailed inputs during the review.

You're welcome. OK, I'll proceed with the CSR.

s'marks


From hohensee at amazon.com  Thu Sep 20 20:52:55 2018
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 20 Sep 2018 20:52:55 +0000
Subject: SSL session cache default maximum number of entries
In-Reply-To: <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com>
References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com>
 <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com>
 <f46628d8-6f4e-ea03-99a9-cbcf456f7145@oracle.com>
 <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com>
 <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com>
Message-ID: <E587095E-BC96-4066-9F8C-587CD7662802@amazon.com>

I've filed https://bugs.openjdk.java.net/browse/JDK-8210985.

Thanks for looking into this.

Paul

?On 9/17/18, 8:37 AM, "Sean Mullan" <sean.mullan at oracle.com> wrote:

    On 9/12/18 2:25 PM, Hohensee, Paul wrote:
    > Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom.
    
    Would you mind filing a bug and we will look into it?
    
    Thanks,
    Sean
    
    > 
    > Paul
    > 
    > On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.mullan at oracle.com> wrote:
    > 
    >      Hi Paul,
    >      
    >      Thank you for bringing this issue to our attention. While we agree that
    >      this does indeed seem like an issue that should be addressed, it is
    >      quite late in the JDK 11 schedule, and it does not appear to be a new
    >      issue introduced in JDK 11. We will be investigating this offline and
    >      will get back to you as soon as we can with more details. Offhand, I
    >      think that we would be able to change the default in an update release.
    >      
    >      Also, you are probably already be aware of this, but you can use the
    >      SSLSessionContext.setSessionCacheSize() API as well as the
    >      "javax.net.ssl.sessionCacheSize" system property to customize the cache
    >      size.
    >      
    >      --Sean
    >      
    >      On 9/11/18 12:02 PM, Sean Mullan wrote:
    >      > cross-posting to security-dev since this is related to SSL/TLS.
    >      >
    >      > On 9/11/18 11:41 AM, Hohensee, Paul wrote:
    >      >> The default value for the maximum number of entries in the SSL session
    >      >> cache (which is a SoftReference cache) is infinite, and the entry
    >      >> timeout is 24 hours. With larger heaps, we?re running into situations
    >      >> where the cache ends up with several million entries when the 24 hours
    >      >> are up. They?re then all invalidated at the same time, resulting in
    >      >> multi-minute pauses (effectively service failures). We?ve experimented
    >      >> with using 10k as the default maximum number of entries with good
    >      >> results (i.e., no latency increases due to sessions falling out of the
    >      >> cache). It?s late and a long shot for JDK11: we?d love to see it
    >      >> changed there because 11 is an LTS release and this is, at least
    >      >> nominally, a behavior change which might not be acceptable in 11u.
    >      >> What do people think?
    >      >>
    >      >> Thanks,
    >      >>
    >      >> Paul
    >      >>
    >      
    > 
    
    


From mandy.chung at oracle.com  Thu Sep 20 20:56:32 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 20 Sep 2018 13:56:32 -0700
Subject: RFR: 8210275: Source Launcher should fail if --source is used
 without a source file
In-Reply-To: <5BA3F03E.7090204@oracle.com>
References: <5BA3F03E.7090204@oracle.com>
Message-ID: <d2dd71c6-80ac-aa6d-9533-6f9d58178f41@oracle.com>

On 9/20/18 12:08 PM, Jonathan Gibbons wrote:
> Please review a small fix to the source launcher that showed up as
> the launcher sometimes ignoring the --source option and finding/running
> a class on the class path.
>
> The problem occurs when the classpath is set after the --source option,
> causing LM_CLASS mode to override the setting of LM_SOURCE.
>
> In addition, some of the error messages that may be reported by the
> source launcher are improved to use "source file" instead of "file" as
> an indication that source-file mode is being used.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210275
> Webrev: http://cr.openjdk.java.net/~jjg/8210275/webrev.00/index.html

This looks fine.

FWIW.? It reads to me that the launcher mode should not be set to LM_CLASS
when parsing -cp option as it does not know the mode until all options are
parsed. Then set to LM_CLASS if mode == LM_UNKNOWN (if not set).
But this requires closer inspection of the current implementation and it's
something for the future.

Mandy

From naoto.sato at oracle.com  Thu Sep 20 21:30:38 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Sep 2018 14:30:38 -0700
Subject: [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
Message-ID: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8210633/webrev.00/

As the submitter pointed out, the overload method that takes Chronology 
needs to be overridden in the anonymous DateTimeTextProvider class.

Naoto

From stuart.marks at oracle.com  Thu Sep 20 21:46:19 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 20 Sep 2018 14:46:19 -0700
Subject: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <5BA299FE.9090406@oracle.com>
References: <5BA299FE.9090406@oracle.com>
Message-ID: <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com>



On 9/19/18 11:48 AM, Joe Wang wrote:
> After much discussion and 10 iterations of reviews, this proposal has evolved 
> from what was the original isSameContent method to a mismatch method. API-wise, 
> a compare method was also considered as it looked like just a short step forward 
> from mismatch, however, it was eventually dropped since there is no convincing 
> use case comparing files lexicographically by contents. Impl-wise, extensive 
> performance benchmarking has been done to compare a buffered reading vs memory 
> mapping, the result was that a simple buffered reading performed better among 
> small files, and those with the mismatched byte closer to the beginning of 
> files. Since the proposed method's targeted files are small ones, the impl 
> currently does a buffered reading only.

Hi Joe,

Thanks for being persistent with this one!

A very small spec nitpick:

> specdiff: 
> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html

1544      *   <li> {@link #isSameFile(Path, Path) isSameFile(path, path2)} 
returns true,</li>

I would add "or" after the trailing comma. This makes it similar to the two-item 
list that follows.

> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/

A couple minor comments on FilesMismatch.java:

If mismatchByAttrs() is replaced with a call to isSameFile(), as Alan suggested, 
this simplifies things considerably. It looks like the mismatch() implementation 
will be reduced to around ~40 lines of code. Does it deserve its own file, or 
can it be placed directly into Files.java? That file has over 4,000 lines 
already though.

  106             if (nRead1 == 0 || nRead2 == 0) {
  107                 if (nRead1 == 0 && nRead2 == 0) {
  108                     // both files reach EOF
  109                     return -1;
  110                 } else {
  111                     // one of the files reaches EOF
  112                     return totalRead;
  113                 }
  114             } else if (nRead1 != nRead2) {

I think it reads slightly better if the nested 'if' at lines 107-113 were 
flattened into the else-if chain, like so:

             if (nRead1 == 0 && nRead2 == 0) {
                 // both files reached EOF
                 return -1;
             } else if (nRead1 == 0 || nRead2 == 0) {
                 // one but not both files reached EOF
                 return totalRead;
             } else if (nRead1 != nRead2) {

There are a couple places where lines can be joined. The resulting lines are 
longer than 80 characters but are still less than 100 characters, which I think 
is OK. (I don't think we have a strict limit of 80 anymore.)

   97     private static long mismatch(InputStream in1, InputStream in2)
   98         throws IOException {

  117                 return totalRead +
  118                     Arrays.mismatch(buffer1, 0, len, buffer2, 0, len);

Comments on tests in Comparison.java:

* This file, and several names within this file, should probably should be 
renamed to focus on mismatch instead of comparison.

* I'm finding it quite difficult to read the test cases.

The test files are placed into a Path[] and referenced by index. This makes it 
quite difficult to determine, for example, if all six cases within the mismatch 
loop are covered.

Instead of storing the files at specific array indexes, I'd suggest doing the 
following.

1) Establish good naming conventions for test files, including size information, 
covering duplicate files (e.g., 'a' and 'b'), and a modification at a particular 
offset. For example, you might do something like the following:

     test120a    - a test file with size 120
     test120b    - a test file with size 120, identical to test120a
     test120m110 - a test file with size 120, with an altered byte at 110
     etc.

2) Declare fields of the same name containing the file paths.

3) Add some logic in prepareTestFile() to append each file's path to a list 
after the file is created. Then have the @AfterClass method run through this 
list and delete the files.

4) The test data generator method can then have lines of test data that 
reference the test files using a meaningful name, so it's easy to understand the 
names and the expected results. Also, the test data generator should have a 
comment that describes the test method parameters.

* The generation of the test data files seems overly complicated.

A StringBuilder is used to accumulate data, then it's turned into a String, then 
(optionally) a character is replaced by the insertChar() method, and then the 
string is written to the file.

I think you can just accumulate the test data into a StringBuilder, (optionally) 
call sb.setCharAt() to modify the data, and then write the SB to the file. After 
all, Files.writeString() takes a CharSequence.

The generateFixedString() method should be changed to create and return a fresh 
StringBuilder with the desired contents. (See above.) It can also be simplified 
quite a bit.

I don't think you need to have methods with Charset parameters. It's reasonable 
to have the test files be text, which makes things easier to develop and debug. 
But the test depends on characters being written in a single-byte charset, 
because mismatch() reports *byte* positions and not *character* positions.

Using the method overloads that are implicitly UTF-8 is incorrect. If a 
non-single-byte character were to slip into the test data (seems unlikely, but 
possible), it'll be expanded to multiple bytes by the UTF-8 encoder, which may 
throw off the result. Instead I'd suggest hardwiring the charset to be US_ASCII 
to enforce the one-byte-per-character invariant.

This is a lot of stuff. If you can't follow it all, perhaps we can work together 
directly and go over the test file.

Thanks,

s'marks

From xu.y.yin at oracle.com  Fri Sep 21 01:51:40 2018
From: xu.y.yin at oracle.com (Chris Yin)
Date: Fri, 21 Sep 2018 09:51:40 +0800
Subject: [12] RFR 8199931:
 java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with
 "incorrect data received"
In-Reply-To: <D7789806-F2CA-49A6-B245-AC9450C11021@oracle.com>
References: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>
 <90667FDA-B316-4E26-B633-C60BD55E4EF4@oracle.com>
 <D7789806-F2CA-49A6-B245-AC9450C11021@oracle.com>
Message-ID: <BF9A4C4D-EF60-49E8-A808-C6BF5A0D4D19@oracle.com>

Hi, Chris H

Thanks for your suggestion, changed as below to just print client bound port as you mentioned. Certainly, this is not a fix, just add some debug info, hope we could get next failure sample to prove the guess :)

New Changes:

diff -r c26fbf1434c4 test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
--- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 14:19:53 2018 -0700
+++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Fri Sep 21 09:45:40 2018 +0800
@@ -120,6 +120,7 @@
         thr.start();
 
         MulticastSocket client = new MulticastSocket(0);
+        System.out.printf("  client bound port: %d%n", client.getLocalPort());
         client.connect(svr.getHost(), svr.getPort());
         pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
         extractRefs(client, "clientMulticastSocket");

Regards,
Chris Y

> On 20 Sep 2018, at 7:11 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Thank you for looking at this issue Chris Y.
> 
> I don?t disagree with the changes, but if you want to confirm your
> suspicion, that the same port is being reused, then printing out
> the client?s bound port would do that ( since the servers port is
> already printed in the logs ). 
> 
> If such a change was integrated, then the next observed failure
> would confirm or disconfirm your suspicion.
> 
> -Chris H.
> 
>> On 20 Sep 2018, at 11:50, Chris Yin <xu.y.yin at oracle.com> wrote:
>> 
>> Loop net-dev since the test is under java/net, thanks
>> 
>>> On 20 Sep 2018, at 5:30 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Please review below minor change for 8199931, thanks
>>> 
>>> A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call ?new MulticastSocket(0)? to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8199931
>>> 
>>> changes:
>>> 
>>> diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
>>> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
>>> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
>>> @@ -40,6 +40,7 @@
>>> import java.net.DatagramSocket;
>>> import java.net.DatagramSocketImpl;
>>> import java.net.InetAddress;
>>> +import java.net.InetSocketAddress;
>>> import java.net.MulticastSocket;
>>> import java.net.UnknownHostException;
>>> import java.nio.file.Files;
>>> @@ -119,7 +120,10 @@
>>>       Thread thr = new Thread(svr);
>>>       thr.start();
>>> 
>>> -        MulticastSocket client = new MulticastSocket(0);
>>> +        MulticastSocket client = new MulticastSocket(null);
>>> +        // prevent MulticastSocket reuse previous address, see 8199931
>>> +        client.setReuseAddress(false);
>>> +        client.bind(new InetSocketAddress(0));
>>>       client.connect(svr.getHost(), svr.getPort());
>>>       pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>>>       extractRefs(client, "clientMulticastSocket?);
>>> 
>>> Regards,
>>> Chris
>> 
> 


From jai.forums2013 at gmail.com  Fri Sep 21 02:01:33 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 21 Sep 2018 07:31:33 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
 <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
 <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>
Message-ID: <3d2763a8-fac9-69ad-7d2e-03184deb4138@gmail.com>



On 21/09/18 1:04 AM, Stuart Marks wrote:
>
>
> Since you mentioned it I'll proceed with "Jaikiran Pai
> <jaikiran.pai at gmail.com>" since that looks a bit more "official". 

Sounds fine to me and yes it indeed is a bit more official one. Thank you.

-Jaikiran

From stuart.marks at oracle.com  Fri Sep 21 02:36:39 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 20 Sep 2018 19:36:39 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <3d2763a8-fac9-69ad-7d2e-03184deb4138@gmail.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
 <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
 <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>
 <3d2763a8-fac9-69ad-7d2e-03184deb4138@gmail.com>
Message-ID: <ceb5be7d-b8a5-cf94-be59-f5d8a7947cdb@oracle.com>

On 9/20/18 7:01 PM, Jaikiran Pai wrote:
>> Since you mentioned it I'll proceed with "Jaikiran Pai
>> <jaikiran.pai at gmail.com>" since that looks a bit more "official".
> 
> Sounds fine to me and yes it indeed is a bit more official one. Thank you.

OK, CSR request posted:

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

Can I get a reviewer for this please? (Sorry Jaikiran, I don't think you can 
review it, as you need to have an OpenJDK user name and a JIRA account. But I'd 
encourage you to take a look to see what I did.)

s'marks

From chris.hegarty at oracle.com  Fri Sep 21 06:37:20 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 21 Sep 2018 07:37:20 +0100
Subject: [12] RFR 8199931:
 java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with
 "incorrect data received"
In-Reply-To: <BF9A4C4D-EF60-49E8-A808-C6BF5A0D4D19@oracle.com>
References: <D5821159-53D6-437A-81EA-13E9FC474946@oracle.com>
 <90667FDA-B316-4E26-B633-C60BD55E4EF4@oracle.com>
 <D7789806-F2CA-49A6-B245-AC9450C11021@oracle.com>
 <BF9A4C4D-EF60-49E8-A808-C6BF5A0D4D19@oracle.com>
Message-ID: <D321E693-8E75-4C76-BC39-9524A00B38BE@oracle.com>

Looks good. Thanks.

-Chris

> On 21 Sep 2018, at 02:51, Chris Yin <xu.y.yin at oracle.com> wrote:
> 
> Hi, Chris H
> 
> Thanks for your suggestion, changed as below to just print client bound port as you mentioned. Certainly, this is not a fix, just add some debug info, hope we could get next failure sample to prove the guess :)
> 
> New Changes:
> 
> diff -r c26fbf1434c4 test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 14:19:53 2018 -0700
> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Fri Sep 21 09:45:40 2018 +0800
> @@ -120,6 +120,7 @@
>          thr.start();
>  
>          MulticastSocket client = new MulticastSocket(0);
> +        System.out.printf("  client bound port: %d%n", client.getLocalPort());
>          client.connect(svr.getHost(), svr.getPort());
>          pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>          extractRefs(client, "clientMulticastSocket");
> 
> Regards,
> Chris Y
> 
>> On 20 Sep 2018, at 7:11 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Thank you for looking at this issue Chris Y.
>> 
>> I don?t disagree with the changes, but if you want to confirm your
>> suspicion, that the same port is being reused, then printing out
>> the client?s bound port would do that ( since the servers port is
>> already printed in the logs ). 
>> 
>> If such a change was integrated, then the next observed failure
>> would confirm or disconfirm your suspicion.
>> 
>> -Chris H.
>> 
>>> On 20 Sep 2018, at 11:50, Chris Yin <xu.y.yin at oracle.com> wrote:
>>> 
>>> Loop net-dev since the test is under java/net, thanks
>>> 
>>>> On 20 Sep 2018, at 5:30 PM, Chris Yin <xu.y.yin at oracle.com> wrote:
>>>> 
>>>> Please review below minor change for 8199931, thanks
>>>> 
>>>> A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call ?new MulticastSocket(0)? to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario.
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8199931
>>>> 
>>>> changes:
>>>> 
>>>> diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java
>>>> --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 08:59:03 2018 +0200
>>>> +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java	Thu Sep 20 16:37:36 2018 +0800
>>>> @@ -40,6 +40,7 @@
>>>> import java.net.DatagramSocket;
>>>> import java.net.DatagramSocketImpl;
>>>> import java.net.InetAddress;
>>>> +import java.net.InetSocketAddress;
>>>> import java.net.MulticastSocket;
>>>> import java.net.UnknownHostException;
>>>> import java.nio.file.Files;
>>>> @@ -119,7 +120,10 @@
>>>>       Thread thr = new Thread(svr);
>>>>       thr.start();
>>>> 
>>>> -        MulticastSocket client = new MulticastSocket(0);
>>>> +        MulticastSocket client = new MulticastSocket(null);
>>>> +        // prevent MulticastSocket reuse previous address, see 8199931
>>>> +        client.setReuseAddress(false);
>>>> +        client.bind(new InetSocketAddress(0));
>>>>       client.connect(svr.getHost(), svr.getPort());
>>>>       pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket"));
>>>>       extractRefs(client, "clientMulticastSocket?);
>>>> 
>>>> Regards,
>>>> Chris
>>> 
>> 
> 

From deepak.kejriwal at oracle.com  Fri Sep 21 09:56:12 2018
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Fri, 21 Sep 2018 02:56:12 -0700 (PDT)
Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of
 empty JAR file
Message-ID: <8a26c2a3-52ca-4d05-a102-2f6ec0341202@default>

Hi all,

 

Please help review the changes for JDK-8199776 to JDK8u:-

 

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

Webrev: http://cr.openjdk.java.net/~rpatil/8199776/webrev.00/

 

Background:-

We have bug JDK-8197398 fixed in jdk 12 where Files.walkFileTree walk indefinitely while processing JAR file with "/" as a directory inside.

Since code for zipfs in jdk8dev different compared to jdk 12, the fix is not exactly same. 

 

Proposed fix:

While iterating over the zip entries added a check to see if entry name is equal to "/" (absolute path). If the entry name is equal to "/" we don't add it to "inodes" map.

 

Regards,

Deepak

From Alan.Bateman at oracle.com  Fri Sep 21 10:22:42 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Sep 2018 11:22:42 +0100
Subject: RFR - JDK-8203442 String::transform (Code Review)
In-Reply-To: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
Message-ID: <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com>

On 18/09/2018 18:52, Jim Laskey wrote:
> Please review the code for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String.
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
I hate to bring up naming but if I have a Stream<String> or 
Optional<String> then I'll use the "map" method to apply the mapping 
function. Has this already been through the naming bike shed and it 
settled on "transform"? Maybe a different name was chosen after looking 
at code that would use it in stream operations? Maybe "transform" was 
used as the argument to the function is always text? I'm not interested 
in re-opening any discussions, just trying to see if options are 
captured in a mail somewhere.

I'm also wondering if this is general enough to be defined by 
CharSequence. Retrofitting CharSequence is always problematic and never 
done lightly but I'm just wondering if it has been discussed and 
dismissed. I don't think it could be done at a later time, at least not 
without changing the input type parameter so that the mapping function 
is Function<? super CharSequence, R> rather than Function<String, R>.

-Alan


From forax at univ-mlv.fr  Fri Sep 21 10:42:26 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 21 Sep 2018 12:42:26 +0200 (CEST)
Subject: RFR - JDK-8203442 String::transform (Code Review)
In-Reply-To: <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com>
References: <74071CC4-A2B4-409C-99E2-8A064E19FBCF@oracle.com>
 <021ecab6-7e06-2ffa-37ba-638df438d144@oracle.com>
Message-ID: <1372178369.83668.1537526546968.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "Jim Laskey" <james.laskey at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 21 Septembre 2018 12:22:42
> Objet: Re: RFR - JDK-8203442 String::transform (Code Review)

> On 18/09/2018 18:52, Jim Laskey wrote:
>> Please review the code for String::transform. The goal is to provide a String
>> instance method to allow function application of custom transformations applied
>> to an instance of String.
>>
>> webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8203442
>> csr: https://bugs.openjdk.java.net/browse/JDK-8203703
> I hate to bring up naming but if I have a Stream<String> or
> Optional<String> then I'll use the "map" method to apply the mapping
> function. Has this already been through the naming bike shed and it
> settled on "transform"? Maybe a different name was chosen after looking
> at code that would use it in stream operations? Maybe "transform" was
> used as the argument to the function is always text? I'm not interested
> in re-opening any discussions, just trying to see if options are
> captured in a mail somewhere.
> 
> I'm also wondering if this is general enough to be defined by
> CharSequence. Retrofitting CharSequence is always problematic and never
> done lightly but I'm just wondering if it has been discussed and
> dismissed. I don't think it could be done at a later time, at least not
> without changing the input type parameter so that the mapping function
> is Function<? super CharSequence, R> rather than Function<String, R>.

the main issue is that a lot of utility methods take a String as parameter, not a CharSequence :(
and Function<? super String, R> is a supertype not a subtype of Function<? super CharSequence, R>.

> 
> -Alan

R?mi

From pavel.rappo at oracle.com  Fri Sep 21 11:16:16 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 21 Sep 2018 12:16:16 +0100
Subject: Reactive Streams utility API
In-Reply-To: <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
 <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>
Message-ID: <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.com>

Hi James,

It sounds like the project is being very active. Glad to hear that! No matter
how good a mailing list is, in practice, it cannot be the best mailing list for
every topic there is. core-libs-dev is no exception. It's good to see you've
found another way to make progress on the project.

The question I was going to ask you was on the implementation internals

    org.reactivestreams.utils.impl.MutexExecutor

However, after examining the new repository, I found that not only has the code
in question disappeared, but the structure of the project has changed as well.

Will the API have the default implementation (ReactiveStreamsEngine)?

-Pavel


From Alan.Bateman at oracle.com  Fri Sep 21 11:32:10 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Sep 2018 12:32:10 +0100
Subject: RFR: 8210275: Source Launcher should fail if --source is used
 without a source file
In-Reply-To: <d2dd71c6-80ac-aa6d-9533-6f9d58178f41@oracle.com>
References: <5BA3F03E.7090204@oracle.com>
 <d2dd71c6-80ac-aa6d-9533-6f9d58178f41@oracle.com>
Message-ID: <0b512726-4fe2-e3c7-1283-0b2362272767@oracle.com>

On 20/09/2018 21:56, mandy chung wrote:
> :
>
> FWIW.? It reads to me that the launcher mode should not be set to LM_CLASS
> when parsing -cp option as it does not know the mode until all options are
> parsed. Then set to LM_CLASS if mode == LM_UNKNOWN (if not set).
> But this requires closer inspection of the current implementation and it's
> something for the future.
This is somewhat fragile area of the launcher code. I don't think the 
processing of --class-path should set the mode as the class path can be 
used in conjunction with other options. The -jar and -m option will 
select the mode of course but other cases should probably leave it as 
LM_UNKNOWN until the final determination with IsSourceFile.

-Alan

From pallavi.sonal at oracle.com  Fri Sep 21 12:26:46 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Fri, 21 Sep 2018 05:26:46 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
Message-ID: <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>

Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
  http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ 

Thanks,
Pallavi Sonal.

-----Original Message-----
From: Stephen Colebourne <scolebourne at joda.org> 
Sent: Thursday, September 20, 2018 6:38 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks for the update.

The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
eg. a negative offset at MAX or a positive offset at MIN.

The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.

thanks
Stephen


On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> Here is the updated webrev for review :
> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>
> Thanks,
> Pallavi Sonal
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Thursday, September 20, 2018 2:50 AM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> handle offsets
>
> Thanks for looking at this.
>
> The proposed fix does not tackle the bug fully. The bug is that the 
> spec says
>
> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>
> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>
> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>
> Furthermore, although there are numerous valid ISO-8601 ways of saying 
> zero, this format uses dashes and colons in the date/time part, so
> ISO-8601 restricts the offset to only those formats that include colons.
>
> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>
> thanks
> Stephen
>
>
> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Hi,
> >
> > Please review the changes to the following issue:
> >
> > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> >
> >
> >
> > The proposed fix is located at:
> >
> > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> >
> >
> >
> > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> >
> >
> >
> > [1] https://en.wikipedia.org/wiki/ISO_8601
> >
> >
> >
> > Thanks,
> >
> > Pallavi Sonal
> >
> >
> >
> >

From brian.goetz at oracle.com  Fri Sep 21 13:25:56 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 21 Sep 2018 09:25:56 -0400
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
 <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>
Message-ID: <8ad4b582-e73d-26bd-2a4e-579b2514dd85@oracle.com>

The example of ISS is a good one.? It is analogous to the question of 
"when is it right to write a class, and when it is right to write a 
function?"? And the answer is, of course, "it depends."? ISS was an 
obvious grouping, but even there there was significant disagreement 
during its design about what it should support and not (especially with 
regard to sum-of-squares calculations), and extra work done to make it 
extensible.? If you're writing from scratch, you might well consider 
writing something like ISS.

But ... the whole motivation for having "teeing" _at all_ is that you 
have some existing collectors you want to reuse!? It seems a little 
silly to claim "I definitely will want to reuse two collectors, so much 
so that we need a new method, but can't imagine ever wanting to reuse 
three."

So, while I am not saying we have to solve the N-way problem now, but I 
think we'd be silly to pick a naming scheme that falls apart when we try 
to go past two.?? So I'm still at "teeing".? It works for two, and it 
works for larger numbers as well.

On 9/16/2018 5:23 AM, Tagir Valeev wrote:
> Hello, Brian!
>
> Regarding more than two collectors. Some libraries definitely have
> analogs (e.g. [1]) which combine more than two collectors. To my
> opinion combining two collectors this way is an upper limit for
> readable code. Especially if you are going to collect to the list, you
> will have a list of untyped and unnamed results which positionally
> correspond to the collectors. If you have more than two collectors to
> combine, writing a separate accumulator class with accept/combine
> methods and creating a collector from the scratch would be much easier
> to read and support. A good example is IntSummaryStatistics and the
> corresponding summarizingInt collector. It could be emulated combining
> four collectors (maxBy, minBy, summingInt, counting), but having a
> dedicated class IntSummaryStatistics which does all four things
> explicitly is much better. It could be easily reused outside of Stream
> API context, it has well-named and well-typed accessor methods and it
> may contain other domain-specific methods like average(). Imagine if
> it were a List of four elements and you had to call summary.get(1) to
> get a maximum. So I think that supporting more than two collectors
> would encourage obscure programming.
>
> With best regards,
> Tagir Valeev
>
> [1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
> (don't ask me why!)
>
> On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
>> to be a name we regret, for reasons outlined below.
>>
>>
>> The behavior of this Collector is:
>>    - duplicate the stream into two identical streams
>>    - collect the two streams with two collectors, yielding two results
>>    - merge the two results into a single result
>>
>> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
>> entirely accurate and explanatory, is "a bit" unwieldy.  So the
>> questions are:
>>    - how much can we drop and still be accurate
>>    - which parts are best to drop.
>>
>> When we pick names, we are not just trying to pick the best name for
>> now, but we should imagine all the possible operations one might ever
>> want to do in the future (names in the JDK are forever) and make a
>> reasonable attempt to imagine whether this could cause confusion or
>> regret in the future.
>>
>> To evaluate "duplexing" here (which seems the most important thing to
>> keep), I'd ask: is there any other reasonable way to imagine a
>> `duplexing` collect operation, now or in the future?
>>
>> One could imagine wanting an operation that takes a stream and produces
>> two streams whose contents are that of the original stream.  And
>> "duplex" is a good name for that.  But, it is not a Collector; it would
>> be a stream transform, like concat.  So that doesn't seem a conflict; a
>> duplexing collector and a duplexing stream transform are sort of from
>> "different namespaces."
>>
>> Can one imagine a "duplexing" Collector that doesn't do any collection?
>> I cannot.  Something that returns a pair of streams would not be a
>> Collector, but something else. So dropping AndCollecting seems justified.
>>
>> What about "AndThenMerging"?  The purpose of collect is to reduce the
>> stream into a summary description.  Can we imagine a duplexing operation
>> that doesn't merge the two results, but instead just returns a tuple of
>> the results?  Yes, I can totally imagine this, especially once we have
>> value types and records, which makes returning ad-hoc tuples cheaper
>> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
>> reasonable possibility. But, I would have no problem with an overload
>> that didn't take a merger and returned a tuple of the result, and was
>> still called `duplexing`.
>>
>> So I'm fine with dropping all the extra AndThisAndThat.
>>
>> Finally, there's one other obvious direction we might extend this --
>> more than two collectors.  There's no reason why we can only do two; we
>> could take a (likely homogeneous) varargs of Collectors, and return a
>> List of results -- which itself could then be streamed into another
>> collector.  This actually sounds pretty useful (though I'm not
>> suggesting doing this right now.) And, I think it would be silly if this
>> were not called the same thing as the two-collector version (just as it
>> would be silly to have separate names for "concat two" and "concat n".)
>>
>> And, this is where I think "duplexing" runs out of gas -- duplex implies
>> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
>> "tee" also has bilateral symmetry, but I don't think you could
>> reasonably argue that a four-way "tee" is not less of an arity abuse
>> than a four-way "duplex", and the plumbing industry would agree:
>>
>> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
>>
>> So, for these reasons, I still think "teeing" has a better balance of
>> being both evocative what it does and likely to stand the test of time.
>>
>>
>>
>>
>> On 9/14/2018 1:09 PM, Stuart Marks wrote:
>>> First, naming. I think "duplex" as the root word wins! Using
>>> "duplexing" to conform to many of other collectors is fine; so,
>>> "duplexing" is good.


From adinn at redhat.com  Fri Sep 21 15:44:14 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 21 Sep 2018 16:44:14 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
Message-ID: <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>

Hi Alan,

Thanks for the response and apologies for failing to notice you had
posted it some days ago (doh!).

Jonathan Halliday has already explained how Red Hat might want to use
this API. Well, what he said, essentially! In particular, this model
provides a way of ensuring that raw byte data is able to be persisted
coherently from Java with the minimal possible overhead. It would be up
to client code above this layer to implement structuring mechanisms for
how those raw bytes get populated with data and to manage any associated
issues regarding atomicity, consistency and isolation (i.e. to provide
the A, C and I of ACID to this API's D).

The main point of the JEP is to ensure that this such a performant base
capability is available for known important cases where that is needed
such as, for example, a transaction manager or a distributed cache. If
equivalent middleware written in C can use persistent memory to bring
the persistent storage tier nearer to the CPU and, hence, lower data
durability overheads then we really need an equivalently performant
option in Java or risk Java dropping out as a player in those middleware
markets.

I am glad to hear that other alternatives might be available and would
be happy to consider them. However, I'm not sure that this means this
option is not still desirable, especially if it is orthogonal to those
other alternatives. Most importantly, this one has the advantage that we
know it is ready to use and will provide benefits (we have already
implemented a journaled transaction log over it with promising results
and someone from our messaging team has already been looking into using
it to persist log messages). Indeed, we also know we can use it to
provide a base for supporting all the use cases addressed by Intel's
libpmem and available to C programmers, e.g. a block store, simply by
implementing Java client libraries that provide managed access to the
persistent buffer along the same lines as the Intel C libraries.

I'm afraid I am not familiar with Panama 'scopes' and 'pointers' so I
can't really compare options here. Can you point me at any info that
explains what those terms mean and how it might be possible to use them
to access off-heap, persistent data.

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 brent.christian at oracle.com  Fri Sep 21 17:41:51 2018
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 21 Sep 2018 10:41:51 -0700
Subject: RFR 12 : 8072130 :
 java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
In-Reply-To: <5BA12F80.1020608@oracle.com>
References: <f708030e-d825-d016-2b8b-763f71403739@oracle.com>
 <0b21704e-8f05-1142-13d4-c17959407eee@oracle.com>
 <5BA12F80.1020608@oracle.com>
Message-ID: <60f7003b-1fb9-3df0-436f-74c86830bad9@oracle.com>

Oops!  I also meant to take the test off of the ProblemList:

test/jdk/ProblemList.txt

*** 515,526 ****
   # jdk_instrument

   java/lang/instrument/RedefineBigClass.sh 
8065756 generic-all
   java/lang/instrument/RetransformBigClass.sh 
8065756 generic-all

- java/lang/instrument/BootClassPath/BootClassPathTest.sh 
8072130 macosx-all
-
   java/lang/management/MemoryMXBean/Pending.java 
8158837 generic-all

(Webrev[1] also updated in place)

Thanks,
-Brent

1. http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/

On 9/18/18 10:01 AM, Xueming Shen wrote:
> +1
> 
> On 9/18/18, 9:42 AM, Brent Christian wrote:
>> Any thoughts on this change?? -B
>>
>> On 9/11/18 3:41 PM, Brent Christian wrote:
>>> Hi,
>>>
>>> Please review this change to how the platform encoding is determined 
>>> on Mac when loading agents.
>>>
>>> Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
>>>
>>> Additional details in the bug report:
>>> https://bugs.openjdk.java.net/browse/JDK-8072130
>>>
>>> Some background:
>>> Since JDK 8, if MacOS reports an encoding of US-ASCII, but no 
>>> encoding hints are provided in environment variables (LANG, LC_ALL, 
>>> LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1].? (This 
>>> allowed apps launched via double-clicked jar to display files 
>>> correctly for non-ASCII languages).
>>>
>>> A similar encoding tweak was not made in the code path used for 
>>> loading agents.
>>>
>>> This can come into play when an agent jar includes a Boot-Class-Path 
>>> entry containing non-ASCII characters.? iconv() gets setup to convert 
>>> UTF-8 to US-ASCII[2], but will fail when encountering extended 
>>> characters in the entry, so the path in question is not added to the 
>>> bootclasspath[3].? This will likely lead to a ClassNotFoundException.
>>>
>>> When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run 
>>> on a?? Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a 
>>> default?? encoding of UTF-8 (per 8011194) and creates Agent.jar with 
>>> a Boot-Class-Path that includes non-ASCII characters.? But the 
>>> Boot-Class-Path entry gets skipped when loading Agent.jar, so the 
>>> AgentSupport class can't be found.
>>>
>>> I propose this be fixed by adding the same UTF-8 encoding adjustment 
>>> on MacOS from 8011194 to the agent loading code path.
>>>
>>> An additional note:
>>> This bug was challenging to reproduce, in large part because the 
>>> 8011194 code checks for an absent env var (getenv() == null), but not 
>>> for env vars with a blank/empty string value (getenv() == ""), so the 
>>> test environment had to be setup in a specific way (e.g. 'unset LANG' 
>>> vs 'export LANG=') to reproduce this bug.? So I'd like to update the 
>>> code to also check for empty string.? I also added a couple small 
>>> improvements to the test.
>>>
>>> Thanks!
>>>
>>> -Brent
>>>
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8011194
>>> 2. 
>>> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 
>>>
>>> 3. 
>>> http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873 
>>>
>>>
> 

From philip.race at oracle.com  Fri Sep 21 20:13:11 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 21 Sep 2018 13:13:11 -0700
Subject: RFR; 8211031: Remove un-needed qualified export to java.desktop from
 java.base on macos
Message-ID: <5BA550D7.6020104@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8211031
webrev: http://cr.openjdk.java.net/~prr/8211031/

Removing some obsolete code which is the reason for a qualified export
from java.base to java.desktop. I also cleaned up some commented out 
debugging code.

See the bug evaluation for more details.

-phil.

From maurizio.cimadamore at oracle.com  Fri Sep 21 20:29:50 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 21 Sep 2018 21:29:50 +0100
Subject: RFR(XS): 8210925 : move bytecode testlibrary to top-level
 testlibrary
In-Reply-To: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
References: <6818AA0C-C149-4112-B690-DB25CA2B5530@oracle.com>
Message-ID: <c81fad23-55ff-0e9b-8d8f-7d2497b1ea4c@oracle.com>

Hi Igor,
I think it would be better to postpone this; we currently have at least 
two different snapshots of the API in various JDK repo - the one you are 
looking at has been added by Paul in order to test condy; Valhalla has 
another (slightly tweaked) version to deal with value type support.

Also, the version of the library in jdk/jdk is missing several fixes and 
improvements added over the last year, which constitutes another reason 
not to move the API into a more central place, as doing so will likely 
give a false sense of confidence that the API/impl is mature enough to 
start building upon it.

That said, I'll register this as a note of positive interest in the API 
- which means that Brian, Robert and I should start thinking about how 
to consolidate all these different snapshot, and working on the API in a 
more transparent way.

I hope this makes sense.

Cheers
Maurizio


On 19/09/18 22:37, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
>> 14 lines changed: 0 ins; 0 del; 14 mod;
> Hi all,
>
> could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory?
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210925
> testing: java/lang/invoke/condy tests
>
> Thanks,
> -- Igor


From mandy.chung at oracle.com  Fri Sep 21 20:45:55 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 21 Sep 2018 13:45:55 -0700
Subject: RFR; 8211031: Remove un-needed qualified export to java.desktop
 from java.base on macos
In-Reply-To: <5BA550D7.6020104@oracle.com>
References: <5BA550D7.6020104@oracle.com>
Message-ID: <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>

Removal of module-info.java.extra is good.

Mandy

On 9/21/18 1:13 PM, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211031
> webrev: http://cr.openjdk.java.net/~prr/8211031/
>
> Removing some obsolete code which is the reason for a qualified export
> from java.base to java.desktop. I also cleaned up some commented out 
> debugging code.
>
> See the bug evaluation for more details.
>
> -phil.


From mandy.chung at oracle.com  Fri Sep 21 21:51:21 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 21 Sep 2018 14:51:21 -0700
Subject: RFR: 8210275: Source Launcher should fail if --source is used
 without a source file
In-Reply-To: <0b512726-4fe2-e3c7-1283-0b2362272767@oracle.com>
References: <5BA3F03E.7090204@oracle.com>
 <d2dd71c6-80ac-aa6d-9533-6f9d58178f41@oracle.com>
 <0b512726-4fe2-e3c7-1283-0b2362272767@oracle.com>
Message-ID: <2e27f06d-59e9-1aa6-6bee-2ec997569fbc@oracle.com>



On 9/21/18 4:32 AM, Alan Bateman wrote:
> On 20/09/2018 21:56, mandy chung wrote:
>> :
>>
>> FWIW.? It reads to me that the launcher mode should not be set to 
>> LM_CLASS
>> when parsing -cp option as it does not know the mode until all 
>> options are
>> parsed. Then set to LM_CLASS if mode == LM_UNKNOWN (if not set).
>> But this requires closer inspection of the current implementation and 
>> it's
>> something for the future.
> This is somewhat fragile area of the launcher code. I don't think the 
> processing of --class-path should set the mode as the class path can 
> be used in conjunction with other options. The -jar and -m option will 
> select the mode of course but other cases should probably leave it as 
> LM_UNKNOWN until the final determination with IsSourceFile.

I file https://bugs.openjdk.java.net/browse/JDK-8211033 and we could 
clean this up in the future.

Mandy

From igor.ignatyev at oracle.com  Fri Sep 21 21:53:54 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 21 Sep 2018 14:53:54 -0700
Subject: <AWT Dev> RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
In-Reply-To: <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>
References: <1124A7A4-0A1C-4C13-9B78-0D3DA5D6B07E@oracle.com>
 <689f4a08-a0d1-32d3-4e25-54280a360c91@oracle.com>
Message-ID: <B93C7069-0EB2-45BF-8267-F3247A56E889@oracle.com>

Hi Sergey,

thanks for your review.

-- Igor

> On Sep 19, 2018, at 2:25 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 19/09/2018 10:18, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>>> 1188 lines changed: 252 ins; 591 del; 345 mod;
>> Hi all,
>> could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/  '/lib/testlibrary/' in the touched tests.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210894
>> testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac
>> Thanks,
>> -- Igor
> 
> 
> -- 
> Best regards, Sergey.


From huizhe.wang at oracle.com  Sat Sep 22 01:49:06 2018
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 21 Sep 2018 18:49:06 -0700
Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing
 file contents
In-Reply-To: <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com>
References: <5BA299FE.9090406@oracle.com>
 <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com>
Message-ID: <5BA59F92.3010601@oracle.com>


On 9/20/18, 2:46 PM, Stuart Marks wrote:
>
>
> On 9/19/18 11:48 AM, Joe Wang wrote:
>> After much discussion and 10 iterations of reviews, this proposal has 
>> evolved from what was the original isSameContent method to a mismatch 
>> method. API-wise, a compare method was also considered as it looked 
>> like just a short step forward from mismatch, however, it was 
>> eventually dropped since there is no convincing use case comparing 
>> files lexicographically by contents. Impl-wise, extensive performance 
>> benchmarking has been done to compare a buffered reading vs memory 
>> mapping, the result was that a simple buffered reading performed 
>> better among small files, and those with the mismatched byte closer 
>> to the beginning of files. Since the proposed method's targeted files 
>> are small ones, the impl currently does a buffered reading only.
>
> Hi Joe,
>
> Thanks for being persistent with this one!

Thanks for the help, and the "lot of stuff" with clear indicators (e.g. 
line numbers and etc.)!  From JDK 11 to 12, hopefully wont be deferred 
to 13 :-)
>
> A very small spec nitpick:
>
>> specdiff: 
>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html
>
> 1544      * <li> {@link #isSameFile(Path, Path) isSameFile(path, 
> path2)} returns true,</li>
>
> I would add "or" after the trailing comma. This makes it similar to 
> the two-item list that follows.

Done.
>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/
>
> A couple minor comments on FilesMismatch.java:
>
> If mismatchByAttrs() is replaced with a call to isSameFile(), as Alan 
> suggested, this simplifies things considerably. It looks like the 
> mismatch() implementation will be reduced to around ~40 lines of code. 
> Does it deserve its own file, or can it be placed directly into 
> Files.java? That file has over 4,000 lines already though.

I merged the private methods after removing mismatchByAttrs(), that 
reduced the code to 33 lines, and then with the change you suggested 
below, it's further reduced to 29 lines. I'll put them in Files for now.

Files is too big,  ~180K, that compares with the next one ~45K among 
files in the nio/file package. Unfortunately, the great majority of them 
are specs, probably 90%.
>
>  106             if (nRead1 == 0 || nRead2 == 0) {
>  107                 if (nRead1 == 0 && nRead2 == 0) {
>  108                     // both files reach EOF
>  109                     return -1;
>  110                 } else {
>  111                     // one of the files reaches EOF
>  112                     return totalRead;
>  113                 }
>  114             } else if (nRead1 != nRead2) {
>
> I think it reads slightly better if the nested 'if' at lines 107-113 
> were flattened into the else-if chain, like so:
>
>             if (nRead1 == 0 && nRead2 == 0) {
>                 // both files reached EOF
>                 return -1;
>             } else if (nRead1 == 0 || nRead2 == 0) {
>                 // one but not both files reached EOF
>                 return totalRead;
>             } else if (nRead1 != nRead2) {
>
> There are a couple places where lines can be joined. The resulting 
> lines are longer than 80 characters but are still less than 100 
> characters, which I think is OK. (I don't think we have a strict limit 
> of 80 anymore.)
>
>   97     private static long mismatch(InputStream in1, InputStream in2)
>   98         throws IOException {
>
>  117                 return totalRead +
>  118                     Arrays.mismatch(buffer1, 0, len, buffer2, 0, 
> len);

Done. 95 characters :-)

>
> Comments on tests in Comparison.java:
>
> * This file, and several names within this file, should probably 
> should be renamed to focus on mismatch instead of comparison.

Will rename to "mismatch". Previously, it covers both mismatch and compare.
>
> * I'm finding it quite difficult to read the test cases.
>
> The test files are placed into a Path[] and referenced by index. This 
> makes it quite difficult to determine, for example, if all six cases 
> within the mismatch loop are covered.
>
> Instead of storing the files at specific array indexes, I'd suggest 
> doing the following.
>
> 1) Establish good naming conventions for test files, including size 
> information, covering duplicate files (e.g., 'a' and 'b'), and a 
> modification at a particular offset. For example, you might do 
> something like the following:
>
>     test120a    - a test file with size 120
>     test120b    - a test file with size 120, identical to test120a
>     test120m110 - a test file with size 120, with an altered byte at 110
>     etc.

I can do that. I had hoped the Assertion msg, e.g. "Both files are 
empty, no mismatch" would help. Along with renaming variables, I will 
also add to the Assertion Msg with test case number, e.g. "Case#1: both 
files are empty, return no mismatch".
>
> 2) Declare fields of the same name containing the file paths.
>
> 3) Add some logic in prepareTestFile() to append each file's path to a 
> list after the file is created. Then have the @AfterClass method run 
> through this list and delete the files.

May also create the test files in a folder and delete it @AfterClass.
>
> 4) The test data generator method can then have lines of test data 
> that reference the test files using a meaningful name, so it's easy to 
> understand the names and the expected results. Also, the test data 
> generator should have a comment that describes the test method 
> parameters.

Sure, will add comments and etc.
>
> * The generation of the test data files seems overly complicated.
>
> A StringBuilder is used to accumulate data, then it's turned into a 
> String, then (optionally) a character is replaced by the insertChar() 
> method, and then the string is written to the file.
>
> I think you can just accumulate the test data into a StringBuilder, 
> (optionally) call sb.setCharAt() to modify the data, and then write 
> the SB to the file. After all, Files.writeString() takes a CharSequence.
>
> The generateFixedString() method should be changed to create and 
> return a fresh StringBuilder with the desired contents. (See above.) 
> It can also be simplified quite a bit.

Wouldn't it be nice if String has an utility method that generates 
random ASCII strings? ;-)  It can be faster with its internal byte array.
>
> I don't think you need to have methods with Charset parameters. It's 
> reasonable to have the test files be text, which makes things easier 
> to develop and debug. But the test depends on characters being written 
> in a single-byte charset, because mismatch() reports *byte* positions 
> and not *character* positions.
>
> Using the method overloads that are implicitly UTF-8 is incorrect. If 
> a non-single-byte character were to slip into the test data (seems 
> unlikely, but possible), it'll be expanded to multiple bytes by the 
> UTF-8 encoder, which may throw off the result. Instead I'd suggest 
> hardwiring the charset to be US_ASCII to enforce the 
> one-byte-per-character invariant.
>
> This is a lot of stuff. If you can't follow it all, perhaps we can 
> work together directly and go over the test file.

I'll improve the test, and US_ASCII it is! I'll probably use a string of 
fixed length to generate the longest string the test needs, and then get 
substrings for other test cases, that may simplify the process.

Thanks,
Joe

>
> Thanks,
>
> s'marks

From philip.race at oracle.com  Sat Sep 22 05:24:53 2018
From: philip.race at oracle.com (Philip Race)
Date: Fri, 21 Sep 2018 22:24:53 -0700
Subject: RFR; 8211031: Remove un-needed qualified export to java.desktop
 from java.base on macos
In-Reply-To: <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>
References: <5BA550D7.6020104@oracle.com>
 <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>
Message-ID: <5BA5D225.3040002@oracle.com>

thanks .. I guess you are deferring review of the rest of it to someone 
from swing.

In that Swing area I have a minor update to the fix :
http://cr.openjdk.java.net/~prr/8211031.1 [*]

since I just realised (meaning just thought to check :-)), that the 
private method
classExists() is called only by the method I have removed .. so 
classExists() can go too ..

-phil.

[*] at this exact moment, cr.openjdk.java.net isn't working but hopefully
that will be fixed by the time anyone reads this :-)

On 9/21/18, 1:45 PM, mandy chung wrote:
> Removal of module-info.java.extra is good.
>
> Mandy
>
> On 9/21/18 1:13 PM, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211031
>> webrev: http://cr.openjdk.java.net/~prr/8211031/
>>
>> Removing some obsolete code which is the reason for a qualified export
>> from java.base to java.desktop. I also cleaned up some commented out 
>> debugging code.
>>
>> See the bug evaluation for more details.
>>
>> -phil.
>

From scolebourne at joda.org  Sun Sep 23 06:57:45 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 23 Sep 2018 07:57:45 +0100
Subject: [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
In-Reply-To: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>
References: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>
Message-ID: <CACzrW9DiZDAoGXFMuJX1A_Rq=cNA5Lt121TF-1iyxakG=8FdpA@mail.gmail.com>

The change seems simple enough.
Does the test prove the change though? I thought the issue was with
months, not years?
Stephen


On Thu, 20 Sep 2018 at 22:32, Naoto Sato <naoto.sato at oracle.com> wrote:
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8210633
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8210633/webrev.00/
>
> As the submitter pointed out, the overload method that takes Chronology
> needs to be overridden in the anonymous DateTimeTextProvider class.
>
> Naoto

From scolebourne at joda.org  Sun Sep 23 07:06:19 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 23 Sep 2018 08:06:19 +0100
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
Message-ID: <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>

Thanks

Can we change the docs to:

<p>
When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
When parsing, the behaviour of {@code appendOffsetId()} will be used
to parse the offset, converting the instant to UTC as necessary.

thanks
Stephen


On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>   http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>
> Thanks,
> Pallavi Sonal.
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Thursday, September 20, 2018 6:38 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>
> Thanks for the update.
>
> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
> eg. a negative offset at MAX or a positive offset at MIN.
>
> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>
> thanks
> Stephen
>
>
> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> > Here is the updated webrev for review :
> > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
> >
> > Thanks,
> > Pallavi Sonal
> >
> > -----Original Message-----
> > From: Stephen Colebourne <scolebourne at joda.org>
> > Sent: Thursday, September 20, 2018 2:50 AM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
> > handle offsets
> >
> > Thanks for looking at this.
> >
> > The proposed fix does not tackle the bug fully. The bug is that the
> > spec says
> >
> > "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
> >
> > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
> >
> > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
> >
> > Furthermore, although there are numerous valid ISO-8601 ways of saying
> > zero, this format uses dashes and colons in the date/time part, so
> > ISO-8601 restricts the offset to only those formats that include colons.
> >
> > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
> >
> > thanks
> > Stephen
> >
> >
> > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > >
> > > Hi,
> > >
> > > Please review the changes to the following issue:
> > >
> > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> > >
> > >
> > >
> > > The proposed fix is located at:
> > >
> > > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> > >
> > >
> > >
> > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> > >
> > >
> > >
> > > [1] https://en.wikipedia.org/wiki/ISO_8601
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Pallavi Sonal
> > >
> > >
> > >
> > >

From amaembo at gmail.com  Mon Sep 24 07:21:21 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 24 Sep 2018 14:21:21 +0700
Subject: Collections.removeIf spec says nothing whether predicate may refer to
 collection
Message-ID: <CAE+3fjb=V64=8f_NOSXPkOnRjcVxEpSmb35eOWRHZ9M9DX4OOw@mail.gmail.com>

Hello!

When using removeIf, sometimes it's tempting to refer to the
collection from the predicate. E.g.:

    static List<Integer> select(Collection<Integer> input) {
        List<Integer> result = new LinkedList<>(input);
        result.removeIf(left -> result.stream().noneMatch(right ->
right == left * 2));
        return result;
    }

Here one may assume that every time the predicate returns true, the
collection is updated and the subsequent predicate invocations see the
updated collection. This works for default removeIf implementation,
but doesn't work for optimized ones like ArrayList, so replacing
LinkedList with ArrayList in this weird algorithm produces different
result (e.g. with List.of(1, 4, 2) input). I think that spec should
explicitly say that intermediate updates are not guaranteed to be
visible for predicate. What do you think?

With best regards,
Tagir Valeev

From Alan.Bateman at oracle.com  Mon Sep 24 08:14:44 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Sep 2018 09:14:44 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
Message-ID: <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>

On 21/09/2018 16:44, Andrew Dinn wrote:
> Hi Alan,
>
> Thanks for the response and apologies for failing to notice you had
> posted it some days ago (doh!).
>
> Jonathan Halliday has already explained how Red Hat might want to use
> this API. Well, what he said, essentially! In particular, this model
> provides a way of ensuring that raw byte data is able to be persisted
> coherently from Java with the minimal possible overhead. It would be up
> to client code above this layer to implement structuring mechanisms for
> how those raw bytes get populated with data and to manage any associated
> issues regarding atomicity, consistency and isolation (i.e. to provide
> the A, C and I of ACID to this API's D).
>
> The main point of the JEP is to ensure that this such a performant base
> capability is available for known important cases where that is needed
> such as, for example, a transaction manager or a distributed cache. If
> equivalent middleware written in C can use persistent memory to bring
> the persistent storage tier nearer to the CPU and, hence, lower data
> durability overheads then we really need an equivalently performant
> option in Java or risk Java dropping out as a player in those middleware
> markets.
>
> I am glad to hear that other alternatives might be available and would
> be happy to consider them. However, I'm not sure that this means this
> option is not still desirable, especially if it is orthogonal to those
> other alternatives. Most importantly, this one has the advantage that we
> know it is ready to use and will provide benefits (we have already
> implemented a journaled transaction log over it with promising results
> and someone from our messaging team has already been looking into using
> it to persist log messages). Indeed, we also know we can use it to
> provide a base for supporting all the use cases addressed by Intel's
> libpmem and available to C programmers, e.g. a block store, simply by
> implementing Java client libraries that provide managed access to the
> persistent buffer along the same lines as the Intel C libraries.
>
> I'm afraid I am not familiar with Panama 'scopes' and 'pointers' so I
> can't really compare options here. Can you point me at any info that
> explains what those terms mean and how it might be possible to use them
> to access off-heap, persistent data.
>
I'm not questioning the need to support NVM, instead I'm trying to see 
whether MappedByteBuffer is the right way to expose this in the standard 
API. Buffers were designed in JSR-51 with specific use-cases in mind but 
they are problematic for many off-heap cases as they aren't thread safe, 
are limited to 2GB, lack confinement, only support homogeneous data (no 
layout support). At the same time, Project Panama (foreign branch in 
panama/dev) has the potential to provide the right API to work with 
memory. I see Jonathan's mail where he seems to be using object 
serialization so the solution on the table works for his use-case but it 
may not be the right solution for more general multi-threaded access to 
NVM. There is some interest in seeing whether this part of Project 
Panama could be advanced to address many of the cases where developers 
are resorting to using Unsafe today. There would of course need to be 
some integration with buffers too. There's no concrete proposal/JEP at 
this time, I'm just pointing out that many of the complaints about 
buffers that are really cases where it's the wrong API and the real need 
is something more fundamental.

So where does this leave us? If support for persistent memory is added 
to FileChannel.map as we've been discussing then it may not be too bad 
as the API surface is small. The API surface is just new map modes and a 
MappedByteBuffer::isPersistent method. The force method that specify a 
range is something useful to add to MBB anyway. If (and I hope when) 
there is support for memory regions or pointers then I could imagine 
re-visiting this so that there are alternative ways to get a memory 
region or pointer that is backed by NVM. If the timing were different 
then I think we'd skip the new map modes and we would be having a 
different discussion here. An alternative is course to create the mapped 
buffer via a JDK-specific API as that would be easier to deprecate and 
remove in the future if needed.

I'm interested to see if there is other input on this topic before it 
gets locked into extending the standard API.

-Alan.

From amaembo at gmail.com  Mon Sep 24 10:39:53 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 24 Sep 2018 17:39:53 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <8ad4b582-e73d-26bd-2a4e-579b2514dd85@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
 <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>
 <8ad4b582-e73d-26bd-2a4e-579b2514dd85@oracle.com>
Message-ID: <CAE+3fjYnrAAaNsof2MYHKQ0C4f6nP8st=aV8uAidtOWnMN-FiA@mail.gmail.com>

Ok, teeing. Webrev updated:
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r6/
CSR updated accordingly:
https://bugs.openjdk.java.net/browse/JDK-8209685

With best regards,
Tagir Valeev.
On Fri, Sep 21, 2018 at 8:26 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> The example of ISS is a good one.  It is analogous to the question of
> "when is it right to write a class, and when it is right to write a
> function?"  And the answer is, of course, "it depends."  ISS was an
> obvious grouping, but even there there was significant disagreement
> during its design about what it should support and not (especially with
> regard to sum-of-squares calculations), and extra work done to make it
> extensible.  If you're writing from scratch, you might well consider
> writing something like ISS.
>
> But ... the whole motivation for having "teeing" _at all_ is that you
> have some existing collectors you want to reuse!  It seems a little
> silly to claim "I definitely will want to reuse two collectors, so much
> so that we need a new method, but can't imagine ever wanting to reuse
> three."
>
> So, while I am not saying we have to solve the N-way problem now, but I
> think we'd be silly to pick a naming scheme that falls apart when we try
> to go past two.   So I'm still at "teeing".  It works for two, and it
> works for larger numbers as well.
>
> On 9/16/2018 5:23 AM, Tagir Valeev wrote:
> > Hello, Brian!
> >
> > Regarding more than two collectors. Some libraries definitely have
> > analogs (e.g. [1]) which combine more than two collectors. To my
> > opinion combining two collectors this way is an upper limit for
> > readable code. Especially if you are going to collect to the list, you
> > will have a list of untyped and unnamed results which positionally
> > correspond to the collectors. If you have more than two collectors to
> > combine, writing a separate accumulator class with accept/combine
> > methods and creating a collector from the scratch would be much easier
> > to read and support. A good example is IntSummaryStatistics and the
> > corresponding summarizingInt collector. It could be emulated combining
> > four collectors (maxBy, minBy, summingInt, counting), but having a
> > dedicated class IntSummaryStatistics which does all four things
> > explicitly is much better. It could be easily reused outside of Stream
> > API context, it has well-named and well-typed accessor methods and it
> > may contain other domain-specific methods like average(). Imagine if
> > it were a List of four elements and you had to call summary.get(1) to
> > get a maximum. So I think that supporting more than two collectors
> > would encourage obscure programming.
> >
> > With best regards,
> > Tagir Valeev
> >
> > [1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
> > (don't ask me why!)
> >
> > On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> >> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
> >> to be a name we regret, for reasons outlined below.
> >>
> >>
> >> The behavior of this Collector is:
> >>    - duplicate the stream into two identical streams
> >>    - collect the two streams with two collectors, yielding two results
> >>    - merge the two results into a single result
> >>
> >> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
> >> entirely accurate and explanatory, is "a bit" unwieldy.  So the
> >> questions are:
> >>    - how much can we drop and still be accurate
> >>    - which parts are best to drop.
> >>
> >> When we pick names, we are not just trying to pick the best name for
> >> now, but we should imagine all the possible operations one might ever
> >> want to do in the future (names in the JDK are forever) and make a
> >> reasonable attempt to imagine whether this could cause confusion or
> >> regret in the future.
> >>
> >> To evaluate "duplexing" here (which seems the most important thing to
> >> keep), I'd ask: is there any other reasonable way to imagine a
> >> `duplexing` collect operation, now or in the future?
> >>
> >> One could imagine wanting an operation that takes a stream and produces
> >> two streams whose contents are that of the original stream.  And
> >> "duplex" is a good name for that.  But, it is not a Collector; it would
> >> be a stream transform, like concat.  So that doesn't seem a conflict; a
> >> duplexing collector and a duplexing stream transform are sort of from
> >> "different namespaces."
> >>
> >> Can one imagine a "duplexing" Collector that doesn't do any collection?
> >> I cannot.  Something that returns a pair of streams would not be a
> >> Collector, but something else. So dropping AndCollecting seems justified.
> >>
> >> What about "AndThenMerging"?  The purpose of collect is to reduce the
> >> stream into a summary description.  Can we imagine a duplexing operation
> >> that doesn't merge the two results, but instead just returns a tuple of
> >> the results?  Yes, I can totally imagine this, especially once we have
> >> value types and records, which makes returning ad-hoc tuples cheaper
> >> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
> >> reasonable possibility. But, I would have no problem with an overload
> >> that didn't take a merger and returned a tuple of the result, and was
> >> still called `duplexing`.
> >>
> >> So I'm fine with dropping all the extra AndThisAndThat.
> >>
> >> Finally, there's one other obvious direction we might extend this --
> >> more than two collectors.  There's no reason why we can only do two; we
> >> could take a (likely homogeneous) varargs of Collectors, and return a
> >> List of results -- which itself could then be streamed into another
> >> collector.  This actually sounds pretty useful (though I'm not
> >> suggesting doing this right now.) And, I think it would be silly if this
> >> were not called the same thing as the two-collector version (just as it
> >> would be silly to have separate names for "concat two" and "concat n".)
> >>
> >> And, this is where I think "duplexing" runs out of gas -- duplex implies
> >> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
> >> "tee" also has bilateral symmetry, but I don't think you could
> >> reasonably argue that a four-way "tee" is not less of an arity abuse
> >> than a four-way "duplex", and the plumbing industry would agree:
> >>
> >> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
> >>
> >> So, for these reasons, I still think "teeing" has a better balance of
> >> being both evocative what it does and likely to stand the test of time.
> >>
> >>
> >>
> >>
> >> On 9/14/2018 1:09 PM, Stuart Marks wrote:
> >>> First, naming. I think "duplex" as the root word wins! Using
> >>> "duplexing" to conform to many of other collectors is fine; so,
> >>> "duplexing" is good.
>

From dan.z.zhou at oracle.com  Mon Sep 24 12:57:19 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Mon, 24 Sep 2018 20:57:19 +0800
Subject: [12]RFR 8210443: Migrate Locale matching tests to JDK Repo.
Message-ID: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>

Hello,

Please help review the fix for migrating GS-auto Locale matching tests 
to JDK repository. Please refer to the bug description for details.

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

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

Regards,
Dora

From martinrb at google.com  Mon Sep 24 16:44:29 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Sep 2018 09:44:29 -0700
Subject: Collections.removeIf spec says nothing whether predicate may
 refer to collection
In-Reply-To: <CAE+3fjb=V64=8f_NOSXPkOnRjcVxEpSmb35eOWRHZ9M9DX4OOw@mail.gmail.com>
References: <CAE+3fjb=V64=8f_NOSXPkOnRjcVxEpSmb35eOWRHZ9M9DX4OOw@mail.gmail.com>
Message-ID: <CA+kOe0_H5pRPSjYx_aHDTBDGODvfkN7iR84JsCwmox8yKaLoRw@mail.gmail.com>

We should have specified that the predicate is not permitted to access
the collection at all, (but subclasses may support it).

In practice, we took care during the implementation of the optimized
removeIf methods to preserve invariants so that predicates that only
access the collection for read will still work but pending updates may
not be applied promptly. But I would not like to make that into a
promise.  I can live with a decision either way, as long as the
predicate is forbidden from mutating.

On Mon, Sep 24, 2018 at 12:21 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> Hello!
>
> When using removeIf, sometimes it's tempting to refer to the
> collection from the predicate. E.g.:
>
>     static List<Integer> select(Collection<Integer> input) {
>         List<Integer> result = new LinkedList<>(input);
>         result.removeIf(left -> result.stream().noneMatch(right ->
> right == left * 2));
>         return result;
>     }
>
> Here one may assume that every time the predicate returns true, the
> collection is updated and the subsequent predicate invocations see the
> updated collection. This works for default removeIf implementation,
> but doesn't work for optimized ones like ArrayList, so replacing
> LinkedList with ArrayList in this weird algorithm produces different
> result (e.g. with List.of(1, 4, 2) input). I think that spec should
> explicitly say that intermediate updates are not guaranteed to be
> visible for predicate. What do you think?
>
> With best regards,
> Tagir Valeev

From daniel.daugherty at oracle.com  Mon Sep 24 16:56:14 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 24 Sep 2018 12:56:14 -0400
Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the
 ProblemList
Message-ID: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>

Greetings,

The following bug was used to ProblemList a couple of tests:

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

Jon's fix for JTREG has been in a promoted JTREG build for
a while now so it's time to remove those tests from the
ProblemList.

Here's the subtask bug to remove the tests from the ProblemList:

 ??? JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList
 ??? https://bugs.openjdk.java.net/browse/JDK-8209019


Here's the diff:

$ hg diff
diff -r 6c17cf410d7c test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400
+++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400
@@ -559,9 +559,6 @@

 ?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.fuchs at oracle.com  Mon Sep 24 17:03:52 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 24 Sep 2018 18:03:52 +0100
Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the
 ProblemList
In-Reply-To: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
Message-ID: <e4981f81-14be-74cb-10d0-080e7ce58346@oracle.com>

Looks good to me Dan!

Let's see if the errant failure reappear...

best regards,

-- daniel

On 24/09/2018 17:56, Daniel D. Daugherty wrote:
> Greetings,
> 
> The following bug was used to ProblemList a couple of tests:
> 
>  ??? JDK-8209018 ProblemList tests affected by JDK-8208690
>  ??? https://bugs.openjdk.java.net/browse/JDK-8209018
> 
> Jon's fix for JTREG has been in a promoted JTREG build for
> a while now so it's time to remove those tests from the
> ProblemList.
> 
> Here's the subtask bug to remove the tests from the ProblemList:
> 
>  ??? JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList
>  ??? https://bugs.openjdk.java.net/browse/JDK-8209019
> 
> 
> Here's the diff:
> 
> $ hg diff
> diff -r 6c17cf410d7c test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400
> +++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400
> @@ -559,9 +559,6 @@
> 
>  ?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 Sep 24 17:04:18 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 24 Sep 2018 13:04:18 -0400
Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the
 ProblemList
In-Reply-To: <e4981f81-14be-74cb-10d0-080e7ce58346@oracle.com>
References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
 <e4981f81-14be-74cb-10d0-080e7ce58346@oracle.com>
Message-ID: <73330dc5-28c8-1ca4-e9a2-c116b9f7849a@oracle.com>

Daniel,

Thanks for the fast review!

Dan


On 9/24/18 1:03 PM, Daniel Fuchs wrote:
> Looks good to me Dan!
>
> Let's see if the errant failure reappear...
>
> best regards,
>
> -- daniel
>
> On 24/09/2018 17:56, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The following bug was used to ProblemList a couple of tests:
>>
>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690
>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018
>>
>> Jon's fix for JTREG has been in a promoted JTREG build for
>> a while now so it's time to remove those tests from the
>> ProblemList.
>>
>> Here's the subtask bug to remove the tests from the ProblemList:
>>
>> ???? JDK-8209019 Remove tests affected by JDK-8208690 from the 
>> ProblemList
>> ???? https://bugs.openjdk.java.net/browse/JDK-8209019
>>
>>
>> Here's the diff:
>>
>> $ hg diff
>> diff -r 6c17cf410d7c test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400
>> +++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400
>> @@ -559,9 +559,6 @@
>>
>> ??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 chris.hegarty at oracle.com  Mon Sep 24 17:18:09 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 24 Sep 2018 18:18:09 +0100
Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the
 ProblemList
In-Reply-To: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
Message-ID: <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com>

Looks good.

-Chris.

> On 24 Sep 2018, at 17:56, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
> Greetings,
> 
> The following bug was used to ProblemList a couple of tests:
> 
>     JDK-8209018 ProblemList tests affected by JDK-8208690
>     https://bugs.openjdk.java.net/browse/JDK-8209018
> 
> Jon's fix for JTREG has been in a promoted JTREG build for
> a while now so it's time to remove those tests from the
> ProblemList.
> 
> Here's the subtask bug to remove the tests from the ProblemList:
> 
>     JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList
>     https://bugs.openjdk.java.net/browse/JDK-8209019
> 
> 
> Here's the diff:
> 
> $ hg diff
> diff -r 6c17cf410d7c test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt    Mon Sep 24 12:18:51 2018 -0400
> +++ b/test/jdk/ProblemList.txt    Mon Sep 24 12:49:53 2018 -0400
> @@ -559,9 +559,6 @@
> 
>  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 naoto.sato at oracle.com  Mon Sep 24 17:34:23 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Sep 2018 10:34:23 -0700
Subject: <i18n dev> [12]RFR 8210443: Migrate Locale matching tests to JDK
 Repo.
In-Reply-To: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
References: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
Message-ID: <da796843-f244-16c0-f890-b21b200e2783@oracle.com>

Looks good to me.

Naoto

On 9/24/18 5:57 AM, Dora Zhou wrote:
> Hello,
> 
> Please help review the fix for migrating GS-auto Locale matching tests 
> to JDK repository. Please refer to the bug description for details.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210443
> 
> Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ 
> <http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/>
> 
> Regards,
> Dora

From nishit.jain at oracle.com  Mon Sep 24 17:51:39 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 24 Sep 2018 23:21:39 +0530
Subject: <i18n dev> [12]RFR 8210443: Migrate Locale matching tests to JDK
 Repo.
In-Reply-To: <da796843-f244-16c0-f890-b21b200e2783@oracle.com>
References: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
 <da796843-f244-16c0-f890-b21b200e2783@oracle.com>
Message-ID: <b4204b10-8365-524a-db17-37bc5d4eb2dd@oracle.com>

+1

On 24-09-2018 23:04, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 9/24/18 5:57 AM, Dora Zhou wrote:
>> Hello,
>>
>> Please help review the fix for migrating GS-auto Locale matching 
>> tests to JDK repository. Please refer to the bug description for 
>> details.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210443
>>
>> Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/>
>>
>> Regards,
>> Dora


From daniel.daugherty at oracle.com  Mon Sep 24 18:37:09 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 24 Sep 2018 14:37:09 -0400
Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the
 ProblemList
In-Reply-To: <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com>
References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com>
 <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com>
Message-ID: <2c6b970b-0782-972e-b2ce-14dc3027ed16@oracle.com>

Chris,

Thanks for the review. I can't list you as a reviewer since I
pushed right after I got dfuch's review.

Dan


On 9/24/18 1:18 PM, Chris Hegarty wrote:
> Looks good.
>
> -Chris.
>
>> On 24 Sep 2018, at 17:56, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> Greetings,
>>
>> The following bug was used to ProblemList a couple of tests:
>>
>>      JDK-8209018 ProblemList tests affected by JDK-8208690
>>      https://bugs.openjdk.java.net/browse/JDK-8209018
>>
>> Jon's fix for JTREG has been in a promoted JTREG build for
>> a while now so it's time to remove those tests from the
>> ProblemList.
>>
>> Here's the subtask bug to remove the tests from the ProblemList:
>>
>>      JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList
>>      https://bugs.openjdk.java.net/browse/JDK-8209019
>>
>>
>> Here's the diff:
>>
>> $ hg diff
>> diff -r 6c17cf410d7c test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt    Mon Sep 24 12:18:51 2018 -0400
>> +++ b/test/jdk/ProblemList.txt    Mon Sep 24 12:49:53 2018 -0400
>> @@ -559,9 +559,6 @@
>>
>>   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 naoto.sato at oracle.com  Mon Sep 24 20:39:32 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Sep 2018 13:39:32 -0700
Subject: [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
In-Reply-To: <CACzrW9DiZDAoGXFMuJX1A_Rq=cNA5Lt121TF-1iyxakG=8FdpA@mail.gmail.com>
References: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>
 <CACzrW9DiZDAoGXFMuJX1A_Rq=cNA5Lt121TF-1iyxakG=8FdpA@mail.gmail.com>
Message-ID: <400d4307-a80f-6aaa-20f8-e59af4d92e85@oracle.com>

Hi Stephen,

Thank you for the review.

On 9/22/18 11:57 PM, Stephen Colebourne wrote:
> The change seems simple enough.
> Does the test prove the change though? I thought the issue was with
> months, not years?

The jira issue refers to both. Added the month-of-year map testing as well:

http://cr.openjdk.java.net/~naoto/8210633/webrev.01/

In fact, the submitter is trying to use this mapping for "Gannen" (first 
year of the era) support for the upcoming Japanese new era (May/2019), 
where formatting the first year would result in "??". Currently, 
j.t.SimpleDateFormat can display this with 'y' pattern, as it is 
calendar specific [1], DateTimeFormatter's 'y' is for digits only.

Naoto

[1] 
https://docs.oracle.com/javase/10/docs/api/java/text/SimpleDateFormat.html#year

> Stephen
> 
> 
> On Thu, 20 Sep 2018 at 22:32, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8210633
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8210633/webrev.00/
>>
>> As the submitter pointed out, the overload method that takes Chronology
>> needs to be overridden in the anonymous DateTimeTextProvider class.
>>
>> Naoto

From joe.darcy at oracle.com  Mon Sep 24 21:47:50 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 24 Sep 2018 14:47:50 -0700
Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for
 enum values() method
Message-ID: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com>

Hello,

Since enum types were added in JDK 5, which shipped GA in 2004, the 
javadoc for the compiler-generated static values() method for enums has 
stated:

> Returns an array containing the constants of this enum type, in the 
> order they are declared. This method may be used to iterate over the 
> constants as follows:
>
> for (RoundingMode c : RoundingMode.values())
> ??? System.out.println(c);

While the tip to use the enhanced for loop to iterate over the constants 
of the enum type may have been reasonable to include in 2004, IMO it is 
unnecessary and clutter in 2018. Therefore, please review the changes for

 ??? JDK-8173730: Stop including enhanced for-loop tip for enum values() 
method
 ??? http://cr.openjdk.java.net/~darcy/8173730.0/

to remove the generation of the for loop tip.

Patch below.

Docs builds complete successfully and elides the tip as expected.

Thanks,

-Joe

--- 
old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 
2018-09-24 14:31:57.943000000 -0700
+++ 
new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 
2018-09-24 14:31:57.771000000 -0700
@@ -230,12 +230,7 @@
 ?#Documentation for Enums
 ?doclet.enum_values_doc.fullbody=\
 ? Returns an array containing the constants of this enum type, in\n\
- the order they are declared. This method may be used to iterate\n\
- over the constants as follows:\n\
- <pre>\n\
- for ({0} c : {0}.values())\n\
- &nbsp;?? System.out.println(c);\n\
- </pre>
+ the order they are declared.

 ?doclet.enum_values_doc.return=\
 ?an array containing the constants of this enum type, in the order they 
are declared


From jonathan.gibbons at oracle.com  Mon Sep 24 22:15:07 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 24 Sep 2018 15:15:07 -0700
Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip
 for enum values() method
In-Reply-To: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com>
References: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com>
Message-ID: <5b4b0cdc-4da7-1426-f8b2-274a0db3df2a@oracle.com>

This will require some thought, Joe, ....

... done. :-)

Looks good to me.

-- Jon


On 9/24/18 2:47 PM, joe darcy wrote:
> Hello,
>
> Since enum types were added in JDK 5, which shipped GA in 2004, the 
> javadoc for the compiler-generated static values() method for enums 
> has stated:
>
>> Returns an array containing the constants of this enum type, in the 
>> order they are declared. This method may be used to iterate over the 
>> constants as follows:
>>
>> for (RoundingMode c : RoundingMode.values())
>> ??? System.out.println(c);
>
> While the tip to use the enhanced for loop to iterate over the 
> constants of the enum type may have been reasonable to include in 
> 2004, IMO it is unnecessary and clutter in 2018. Therefore, please 
> review the changes for
>
> ??? JDK-8173730: Stop including enhanced for-loop tip for enum 
> values() method
> ??? http://cr.openjdk.java.net/~darcy/8173730.0/
>
> to remove the generation of the for loop tip.
>
> Patch below.
>
> Docs builds complete successfully and elides the tip as expected.
>
> Thanks,
>
> -Joe
>
> --- 
> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 
> 2018-09-24 14:31:57.943000000 -0700
> +++ 
> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 
> 2018-09-24 14:31:57.771000000 -0700
> @@ -230,12 +230,7 @@
> ?#Documentation for Enums
> ?doclet.enum_values_doc.fullbody=\
> ? Returns an array containing the constants of this enum type, in\n\
> - the order they are declared. This method may be used to iterate\n\
> - over the constants as follows:\n\
> - <pre>\n\
> - for ({0} c : {0}.values())\n\
> - &nbsp;?? System.out.println(c);\n\
> - </pre>
> + the order they are declared.
>
> ?doclet.enum_values_doc.return=\
> ?an array containing the constants of this enum type, in the order 
> they are declared
>


From stuart.marks at oracle.com  Tue Sep 25 00:33:04 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 24 Sep 2018 17:33:04 -0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <CAE+3fjYnrAAaNsof2MYHKQ0C4f6nP8st=aV8uAidtOWnMN-FiA@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>
 <3c99c2fb-ccd7-0bc6-640b-44498dc73e9e@oracle.com>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
 <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>
 <8ad4b582-e73d-26bd-2a4e-579b2514dd85@oracle.com>
 <CAE+3fjYnrAAaNsof2MYHKQ0C4f6nP8st=aV8uAidtOWnMN-FiA@mail.gmail.com>
Message-ID: <183d9510-d4ac-2d90-2472-60d1d363bb18@oracle.com>

Webrev looks good.

In the CSR, I updated the webrev link to point to the latest, I set the 
fix-version to 12, and I set the scope to SE. I've marked the CSR reviewed.

The next thing is for you to mark the CSR as Finalized.

Thanks,

s'marks


On 9/24/18 3:39 AM, Tagir Valeev wrote:
> Ok, teeing. Webrev updated:
> http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r6/
> CSR updated accordingly:
> https://bugs.openjdk.java.net/browse/JDK-8209685
> 
> With best regards,
> Tagir Valeev.
> On Fri, Sep 21, 2018 at 8:26 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> The example of ISS is a good one.  It is analogous to the question of
>> "when is it right to write a class, and when it is right to write a
>> function?"  And the answer is, of course, "it depends."  ISS was an
>> obvious grouping, but even there there was significant disagreement
>> during its design about what it should support and not (especially with
>> regard to sum-of-squares calculations), and extra work done to make it
>> extensible.  If you're writing from scratch, you might well consider
>> writing something like ISS.
>>
>> But ... the whole motivation for having "teeing" _at all_ is that you
>> have some existing collectors you want to reuse!  It seems a little
>> silly to claim "I definitely will want to reuse two collectors, so much
>> so that we need a new method, but can't imagine ever wanting to reuse
>> three."
>>
>> So, while I am not saying we have to solve the N-way problem now, but I
>> think we'd be silly to pick a naming scheme that falls apart when we try
>> to go past two.   So I'm still at "teeing".  It works for two, and it
>> works for larger numbers as well.
>>
>> On 9/16/2018 5:23 AM, Tagir Valeev wrote:
>>> Hello, Brian!
>>>
>>> Regarding more than two collectors. Some libraries definitely have
>>> analogs (e.g. [1]) which combine more than two collectors. To my
>>> opinion combining two collectors this way is an upper limit for
>>> readable code. Especially if you are going to collect to the list, you
>>> will have a list of untyped and unnamed results which positionally
>>> correspond to the collectors. If you have more than two collectors to
>>> combine, writing a separate accumulator class with accept/combine
>>> methods and creating a collector from the scratch would be much easier
>>> to read and support. A good example is IntSummaryStatistics and the
>>> corresponding summarizingInt collector. It could be emulated combining
>>> four collectors (maxBy, minBy, summingInt, counting), but having a
>>> dedicated class IntSummaryStatistics which does all four things
>>> explicitly is much better. It could be easily reused outside of Stream
>>> API context, it has well-named and well-typed accessor methods and it
>>> may contain other domain-specific methods like average(). Imagine if
>>> it were a List of four elements and you had to call summary.get(1) to
>>> get a maximum. So I think that supporting more than two collectors
>>> would encourage obscure programming.
>>>
>>> With best regards,
>>> Tagir Valeev
>>>
>>> [1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
>>> (don't ask me why!)
>>>
>>> On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>>>> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
>>>> to be a name we regret, for reasons outlined below.
>>>>
>>>>
>>>> The behavior of this Collector is:
>>>>     - duplicate the stream into two identical streams
>>>>     - collect the two streams with two collectors, yielding two results
>>>>     - merge the two results into a single result
>>>>
>>>> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
>>>> entirely accurate and explanatory, is "a bit" unwieldy.  So the
>>>> questions are:
>>>>     - how much can we drop and still be accurate
>>>>     - which parts are best to drop.
>>>>
>>>> When we pick names, we are not just trying to pick the best name for
>>>> now, but we should imagine all the possible operations one might ever
>>>> want to do in the future (names in the JDK are forever) and make a
>>>> reasonable attempt to imagine whether this could cause confusion or
>>>> regret in the future.
>>>>
>>>> To evaluate "duplexing" here (which seems the most important thing to
>>>> keep), I'd ask: is there any other reasonable way to imagine a
>>>> `duplexing` collect operation, now or in the future?
>>>>
>>>> One could imagine wanting an operation that takes a stream and produces
>>>> two streams whose contents are that of the original stream.  And
>>>> "duplex" is a good name for that.  But, it is not a Collector; it would
>>>> be a stream transform, like concat.  So that doesn't seem a conflict; a
>>>> duplexing collector and a duplexing stream transform are sort of from
>>>> "different namespaces."
>>>>
>>>> Can one imagine a "duplexing" Collector that doesn't do any collection?
>>>> I cannot.  Something that returns a pair of streams would not be a
>>>> Collector, but something else. So dropping AndCollecting seems justified.
>>>>
>>>> What about "AndThenMerging"?  The purpose of collect is to reduce the
>>>> stream into a summary description.  Can we imagine a duplexing operation
>>>> that doesn't merge the two results, but instead just returns a tuple of
>>>> the results?  Yes, I can totally imagine this, especially once we have
>>>> value types and records, which makes returning ad-hoc tuples cheaper
>>>> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
>>>> reasonable possibility. But, I would have no problem with an overload
>>>> that didn't take a merger and returned a tuple of the result, and was
>>>> still called `duplexing`.
>>>>
>>>> So I'm fine with dropping all the extra AndThisAndThat.
>>>>
>>>> Finally, there's one other obvious direction we might extend this --
>>>> more than two collectors.  There's no reason why we can only do two; we
>>>> could take a (likely homogeneous) varargs of Collectors, and return a
>>>> List of results -- which itself could then be streamed into another
>>>> collector.  This actually sounds pretty useful (though I'm not
>>>> suggesting doing this right now.) And, I think it would be silly if this
>>>> were not called the same thing as the two-collector version (just as it
>>>> would be silly to have separate names for "concat two" and "concat n".)
>>>>
>>>> And, this is where I think "duplexing" runs out of gas -- duplex implies
>>>> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
>>>> "tee" also has bilateral symmetry, but I don't think you could
>>>> reasonably argue that a four-way "tee" is not less of an arity abuse
>>>> than a four-way "duplex", and the plumbing industry would agree:
>>>>
>>>> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
>>>>
>>>> So, for these reasons, I still think "teeing" has a better balance of
>>>> being both evocative what it does and likely to stand the test of time.
>>>>
>>>>
>>>>
>>>>
>>>> On 9/14/2018 1:09 PM, Stuart Marks wrote:
>>>>> First, naming. I think "duplex" as the root word wins! Using
>>>>> "duplexing" to conform to many of other collectors is fine; so,
>>>>> "duplexing" is good.
>>

From amaembo at gmail.com  Tue Sep 25 03:15:04 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 25 Sep 2018 10:15:04 +0700
Subject: RFR: JDK-8205461 Create Collector which merges results of two
 other collectors
In-Reply-To: <183d9510-d4ac-2d90-2472-60d1d363bb18@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>
 <CAE+3fjZuoOLd4ozB5Bf0ZWbfHHq9ELqfvJens0jEcVHRqAo2eA@mail.gmail.com>
 <829381c3-80c8-1fa5-de8d-a8364b8c6405@gmail.com>
 <CAD4YxQWdQdzp=C2Xe3-=J3w8sOq=YtM1+=ncSof7=V_Wm84juQ@mail.gmail.com>
 <1ba2d793-66ba-e7e9-ba6d-c160344e557a@oracle.com>
 <5fe26010-e5dd-3cc4-35ac-6260011c2172@oracle.com>
 <CAE+3fjbUBK-K7QbkCw68iGAT-ys-wjXYP1f4_cq55H=boFdUMg@mail.gmail.com>
 <8ad4b582-e73d-26bd-2a4e-579b2514dd85@oracle.com>
 <CAE+3fjYnrAAaNsof2MYHKQ0C4f6nP8st=aV8uAidtOWnMN-FiA@mail.gmail.com>
 <183d9510-d4ac-2d90-2472-60d1d363bb18@oracle.com>
Message-ID: <CAE+3fjbqt+2vemLP=53qQTremXcB-wmZ6aSAfAiBoEet6BAavQ@mail.gmail.com>

> In the CSR, I updated the webrev link to point to the latest, I set the
> fix-version to 12, and I set the scope to SE. I've marked the CSR reviewed.
>
> The next thing is for you to mark the CSR as Finalized.

Done, thanks!

With best regards,
Tagir Valeev


>
> Thanks,
>
> s'marks
>
>
> On 9/24/18 3:39 AM, Tagir Valeev wrote:
> > Ok, teeing. Webrev updated:
> > http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r6/
> > CSR updated accordingly:
> > https://bugs.openjdk.java.net/browse/JDK-8209685
> >
> > With best regards,
> > Tagir Valeev.
> > On Fri, Sep 21, 2018 at 8:26 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> >>
> >> The example of ISS is a good one.  It is analogous to the question of
> >> "when is it right to write a class, and when it is right to write a
> >> function?"  And the answer is, of course, "it depends."  ISS was an
> >> obvious grouping, but even there there was significant disagreement
> >> during its design about what it should support and not (especially with
> >> regard to sum-of-squares calculations), and extra work done to make it
> >> extensible.  If you're writing from scratch, you might well consider
> >> writing something like ISS.
> >>
> >> But ... the whole motivation for having "teeing" _at all_ is that you
> >> have some existing collectors you want to reuse!  It seems a little
> >> silly to claim "I definitely will want to reuse two collectors, so much
> >> so that we need a new method, but can't imagine ever wanting to reuse
> >> three."
> >>
> >> So, while I am not saying we have to solve the N-way problem now, but I
> >> think we'd be silly to pick a naming scheme that falls apart when we try
> >> to go past two.   So I'm still at "teeing".  It works for two, and it
> >> works for larger numbers as well.
> >>
> >> On 9/16/2018 5:23 AM, Tagir Valeev wrote:
> >>> Hello, Brian!
> >>>
> >>> Regarding more than two collectors. Some libraries definitely have
> >>> analogs (e.g. [1]) which combine more than two collectors. To my
> >>> opinion combining two collectors this way is an upper limit for
> >>> readable code. Especially if you are going to collect to the list, you
> >>> will have a list of untyped and unnamed results which positionally
> >>> correspond to the collectors. If you have more than two collectors to
> >>> combine, writing a separate accumulator class with accept/combine
> >>> methods and creating a collector from the scratch would be much easier
> >>> to read and support. A good example is IntSummaryStatistics and the
> >>> corresponding summarizingInt collector. It could be emulated combining
> >>> four collectors (maxBy, minBy, summingInt, counting), but having a
> >>> dedicated class IntSummaryStatistics which does all four things
> >>> explicitly is much better. It could be easily reused outside of Stream
> >>> API context, it has well-named and well-typed accessor methods and it
> >>> may contain other domain-specific methods like average(). Imagine if
> >>> it were a List of four elements and you had to call summary.get(1) to
> >>> get a maximum. So I think that supporting more than two collectors
> >>> would encourage obscure programming.
> >>>
> >>> With best regards,
> >>> Tagir Valeev
> >>>
> >>> [1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
> >>> (don't ask me why!)
> >>>
> >>> On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> >>>> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
> >>>> to be a name we regret, for reasons outlined below.
> >>>>
> >>>>
> >>>> The behavior of this Collector is:
> >>>>     - duplicate the stream into two identical streams
> >>>>     - collect the two streams with two collectors, yielding two results
> >>>>     - merge the two results into a single result
> >>>>
> >>>> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
> >>>> entirely accurate and explanatory, is "a bit" unwieldy.  So the
> >>>> questions are:
> >>>>     - how much can we drop and still be accurate
> >>>>     - which parts are best to drop.
> >>>>
> >>>> When we pick names, we are not just trying to pick the best name for
> >>>> now, but we should imagine all the possible operations one might ever
> >>>> want to do in the future (names in the JDK are forever) and make a
> >>>> reasonable attempt to imagine whether this could cause confusion or
> >>>> regret in the future.
> >>>>
> >>>> To evaluate "duplexing" here (which seems the most important thing to
> >>>> keep), I'd ask: is there any other reasonable way to imagine a
> >>>> `duplexing` collect operation, now or in the future?
> >>>>
> >>>> One could imagine wanting an operation that takes a stream and produces
> >>>> two streams whose contents are that of the original stream.  And
> >>>> "duplex" is a good name for that.  But, it is not a Collector; it would
> >>>> be a stream transform, like concat.  So that doesn't seem a conflict; a
> >>>> duplexing collector and a duplexing stream transform are sort of from
> >>>> "different namespaces."
> >>>>
> >>>> Can one imagine a "duplexing" Collector that doesn't do any collection?
> >>>> I cannot.  Something that returns a pair of streams would not be a
> >>>> Collector, but something else. So dropping AndCollecting seems justified.
> >>>>
> >>>> What about "AndThenMerging"?  The purpose of collect is to reduce the
> >>>> stream into a summary description.  Can we imagine a duplexing operation
> >>>> that doesn't merge the two results, but instead just returns a tuple of
> >>>> the results?  Yes, I can totally imagine this, especially once we have
> >>>> value types and records, which makes returning ad-hoc tuples cheaper
> >>>> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
> >>>> reasonable possibility. But, I would have no problem with an overload
> >>>> that didn't take a merger and returned a tuple of the result, and was
> >>>> still called `duplexing`.
> >>>>
> >>>> So I'm fine with dropping all the extra AndThisAndThat.
> >>>>
> >>>> Finally, there's one other obvious direction we might extend this --
> >>>> more than two collectors.  There's no reason why we can only do two; we
> >>>> could take a (likely homogeneous) varargs of Collectors, and return a
> >>>> List of results -- which itself could then be streamed into another
> >>>> collector.  This actually sounds pretty useful (though I'm not
> >>>> suggesting doing this right now.) And, I think it would be silly if this
> >>>> were not called the same thing as the two-collector version (just as it
> >>>> would be silly to have separate names for "concat two" and "concat n".)
> >>>>
> >>>> And, this is where I think "duplexing" runs out of gas -- duplex implies
> >>>> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
> >>>> "tee" also has bilateral symmetry, but I don't think you could
> >>>> reasonably argue that a four-way "tee" is not less of an arity abuse
> >>>> than a four-way "duplex", and the plumbing industry would agree:
> >>>>
> >>>> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
> >>>>
> >>>> So, for these reasons, I still think "teeing" has a better balance of
> >>>> being both evocative what it does and likely to stand the test of time.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 9/14/2018 1:09 PM, Stuart Marks wrote:
> >>>>> First, naming. I think "duplex" as the root word wins! Using
> >>>>> "duplexing" to conform to many of other collectors is fine; so,
> >>>>> "duplexing" is good.
> >>

From james at lightbend.com  Tue Sep 25 04:33:58 2018
From: james at lightbend.com (James Roper)
Date: Tue, 25 Sep 2018 14:33:58 +1000
Subject: Reactive Streams utility API
In-Reply-To: <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
 <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>
 <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.com>
Message-ID: <CABY0rKPiKd6gTQ6eUrcq8WQPDTEMgzEm1=vWSaxfDOhbVkn+Yg@mail.gmail.com>

Hi Pavel,

MicroProfile doesn't do implementations, or even have a concept of a
reference implementation, which is why that executor isn't there. It is
however in one of the implementations of the spec that we've created at
Lightbend:

https://github.com/lightbend/microprofile-reactive-streams/blob/master/zerodep/src/main/java/com/lightbend/microprofile/reactive/streams/zerodep/MutexExecutor.java

This implementation is being called a "zero dependency" implementation,
since it doesn't bring in any other dependencies, unlike the implementation
that we are going to use ourselves, which uses Akka Streams. The zerodep
implementation isn't production ready, our main reason for providing it is
as a candidate starting point for a reference implementation in the JDK.
But I also don't think it's that bad an implementation, it's just that
unlike the Akka Streams based implementation (or any of the other
implementations, eg RedHat's one built on RxJava and Vert.x), it has not
been proven through any real world use.

As for the MutexExecutor itself, that was mostly written by Viktor Klang,
and I believe he wrote it based on his experience implementing similar
constructs for Akka mailboxes. There is one major problem with it that I'm
aware of - it's not fair on the underlying executor. If you submit tasks at
an equal or higher rate than can be processed by a single thread, the
executor will never return the thread it uses to the underlying executor. I
don't think that's hard to fix - we could limit the number of sequential
tasks it does on a thread before resubmitting to the underlying executor.

A slightly different incarnation of this problem is when each task invoked
resubmits another task, for example, using the current reactive streams
API, if I did ReactiveStreams.generate(() ->
"foo").forEach(System.out::println), that is by design effectively an
infinite loop that prints out foo, but being an asynchronous API it
shouldn't actually be an infinite loop, it should return the thread back to
the underlying executor at least periodically to allow that thread to be
used for other tasks queued on the executor, but it doesn't do that.

But this issue (and some similar issues that may exist) we haven't begun to
consider addressing, primarily because fixing it requires selecting some
magic numbers for limits on work to do, and they can't be selected without
some realistic benchmarks being created to tune them to, and we're just not
ready to take this implementation to that level, it could change very
significantly which would change all the assumptions before it's ready to
be used.

Cheers,

James

On Fri, 21 Sep 2018 at 21:16, Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Hi James,
>
> It sounds like the project is being very active. Glad to hear that! No
> matter
> how good a mailing list is, in practice, it cannot be the best mailing
> list for
> every topic there is. core-libs-dev is no exception. It's good to see
> you've
> found another way to make progress on the project.
>
> The question I was going to ask you was on the implementation internals
>
>     org.reactivestreams.utils.impl.MutexExecutor
>
> However, after examining the new repository, I found that not only has the
> code
> in question disappeared, but the structure of the project has changed as
> well.
>
> Will the API have the default implementation (ReactiveStreamsEngine)?
>
> -Pavel
>
>

-- 
*James Roper*
*Senior Developer, Office of the CTO*

Lightbend <https://www.lightbend.com/> ? Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>

From deepak.kejriwal at oracle.com  Tue Sep 25 05:53:11 2018
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Mon, 24 Sep 2018 22:53:11 -0700 (PDT)
Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents
 of empty JAR file
In-Reply-To: <8a26c2a3-52ca-4d05-a102-2f6ec0341202@default>
References: <8a26c2a3-52ca-4d05-a102-2f6ec0341202@default>
Message-ID: <712048a3-cf49-4824-8541-d689640f41b2@default>

Hi,

Gentle reminder for review below fix.

Regards,
Deepak

-----Original Message-----
From: Deepak Kejriwal 
Sent: Friday, September 21, 2018 3:26 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of empty JAR file

Hi all,

 

Please help review the changes for JDK-8199776 to JDK8u:-

 

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

Webrev: http://cr.openjdk.java.net/~rpatil/8199776/webrev.00/

 

Background:-

We have bug JDK-8197398 fixed in jdk 12 where Files.walkFileTree walk indefinitely while processing JAR file with "/" as a directory inside.

Since code for zipfs in jdk8dev different compared to jdk 12, the fix is not exactly same. 

 

Proposed fix:

While iterating over the zip entries added a check to see if entry name is equal to "/" (absolute path). If the entry name is equal to "/" we don't add it to "inodes" map.

 

Regards,

Deepak

From zhangbodut at gmail.com  Tue Sep 25 06:27:07 2018
From: zhangbodut at gmail.com (Bo Zhang)
Date: Tue, 25 Sep 2018 14:27:07 +0800
Subject: [PATCH] 8210810: Incorrect argument file parser behavior in certain
 cases
Message-ID: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>

Hi all,

This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed the OCA with the name ?Bo Zhang?.

Bug description:

8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>: Incorrect argument file parser behavior in certain cases

Previously, if a quoted backslash character appears at argument file
parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
file is backslash '\'), the segment before the backslash character will
be added into argument twice due to a missing anchor position reset
operation.

For example, you have an argument file:

-cp "...a\\b"

and the 4096th and 4097th characters happen to be both '\', the result
generated by the argument file parser would be:

-cp "...aa\\b?

This patch fixes the issue by resetting anchor position correctly
in this case.

I?m a little surprised that this issue has existed for several years unnoticed.


Patch:

# HG changeset patch
# User Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>>
# Date 1537835887 -28800
#      Tue Sep 25 08:38:07 2018 +0800
# Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352
# Parent  16f0deae8fa6ef85f7230308e1fe7556bd007c39
8210810: Incorrect argument file parser behavior in certain cases

Previously, if a quoted backslash character appears at argument file
parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
file is backslash '\'), the segment before the backslash character will
be added into argument twice due to a missing anchor position reset
operation.

For example, you have an argument file:

-cp "...a\\b"

and the 4096th and 4097th characters happen to be both '\', the result
generated by the argument file parser would be:

-cp "...aa\\b"

This patch fixes the issue by resetting anchor position correctly
in this case.

diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c
--- a/src/java.base/share/native/libjli/args.c
+++ b/src/java.base/share/native/libjli/args.c
@@ -262,6 +262,8 @@
                     continue;
                 }
                 JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor);
+                // anchor after backslash character
+                anchor = nextc + 1;
                 pctx->state = IN_ESCAPE;
                 break;
             case '\'':
diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/tools/launcher/Test8210810.java
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com <http://www.oracle.com/> if you need additional information or have any
+ * questions.
+ */
+
+/*
+ * @test
+ * @bug 8210810
+ * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary
+ * @modules java.base
+ * @author Bo Zhang
+ * @build TestHelper
+ * @run main Test8210810
+ */
+
+/*
+ * 8210810: Previously, if a quoted backslash character appears at argument file
+ * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
+ * file is backslash '\'), the segment before the backslash character will
+ * be added into argument twice due to a missing anchor position reset
+ * operation. This test creates a special argument file which can reproduce this issue.
+ */
+import java.io.File;
+import java.nio.file.Files;
+import java.io.IOException;
+import java.util.Arrays;
+
+public class Test8210810 extends TestHelper {
+    // Buffer size in args.c readArgFile() method
+    private static final int ARG_FILE_PARSER_BUF_SIZE = 4096;
+    public static void main(String... args) throws Exception {
+        new Test8210810().canParseArgFileCorrectly();
+    }
+
+    private void canParseArgFileCorrectly() throws IOException {
+        File testJar = createTestClassWhichPrintsClasspath();
+        File argFile = createArgFileWithSpecificClasspath();
+        TestResult result = doExec(javaCmd, "@argFile", "Foo");
+
+        long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath())));
+        long zCountReadByParser = countZ(result.testOutput.get(0));
+        if(zCountInArgFile != zCountReadByParser) {
+            throw new RuntimeException("Classpath parsed by parser is different from argument file!");
+        }
+
+        testJar.delete();
+        argFile.delete();
+    }
+
+    private long countZ(String str) {
+        return str.chars().filter(ch -> ch == 'z').count();
+    }
+
+    private File createTestClassWhichPrintsClasspath() throws IOException {
+        File testJar = new File("test.jar");
+        testJar.delete();
+
+        StringBuilder tsrc = new StringBuilder();
+        tsrc.append("public static void main(String... args) {\n");
+        tsrc.append("   System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n");
+        tsrc.append("}\n");
+        createJar(testJar, new File("Foo"), tsrc.toString());
+        return testJar;
+    }
+
+    // Create a file whose 4096th and 4097th characters are both '\' (backslash)
+    // File content:
+    // |-cp "test.jar:zzzzz...zzz\\"|
+    private File createArgFileWithSpecificClasspath() throws IOException {
+        File argFile = new File("argFile");
+        argFile.delete();
+
+        StringBuilder arg = new StringBuilder("-cp \"test.jar");
+        arg.append(File.pathSeparator);
+
+        int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length();
+
+        for(int i = 0; i < fillingCharactersCount; ++i) {
+            arg.append('z');
+        }
+
+        arg.append('\\'); // 4096th character in the arg file
+        arg.append('\\'); // 4097th character in the arg file
+        arg.append('"');
+
+        createAFile(argFile, Arrays.asList(arg.toString()));
+        return argFile;
+    }
+}

Unit test:

Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical.




From scolebourne at joda.org  Tue Sep 25 07:19:29 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 25 Sep 2018 08:19:29 +0100
Subject: [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
In-Reply-To: <400d4307-a80f-6aaa-20f8-e59af4d92e85@oracle.com>
References: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>
 <CACzrW9DiZDAoGXFMuJX1A_Rq=cNA5Lt121TF-1iyxakG=8FdpA@mail.gmail.com>
 <400d4307-a80f-6aaa-20f8-e59af4d92e85@oracle.com>
Message-ID: <CACzrW9AJyhxj=UXPXj5AJ0x+8_7H5XaP-FCZrFxvER243U00Ug@mail.gmail.com>

Thanks, +1 from me (not an OpenJDK reviewer).
Stephen

On Mon, 24 Sep 2018 at 21:40, Naoto Sato <naoto.sato at oracle.com> wrote:
>
> Hi Stephen,
>
> Thank you for the review.
>
> On 9/22/18 11:57 PM, Stephen Colebourne wrote:
> > The change seems simple enough.
> > Does the test prove the change though? I thought the issue was with
> > months, not years?
>
> The jira issue refers to both. Added the month-of-year map testing as well:
>
> http://cr.openjdk.java.net/~naoto/8210633/webrev.01/
>
> In fact, the submitter is trying to use this mapping for "Gannen" (first
> year of the era) support for the upcoming Japanese new era (May/2019),
> where formatting the first year would result in "??". Currently,
> j.t.SimpleDateFormat can display this with 'y' pattern, as it is
> calendar specific [1], DateTimeFormatter's 'y' is for digits only.
>
> Naoto
>
> [1]
> https://docs.oracle.com/javase/10/docs/api/java/text/SimpleDateFormat.html#year
>
> > Stephen
> >
> >
> > On Thu, 20 Sep 2018 at 22:32, Naoto Sato <naoto.sato at oracle.com> wrote:
> >>
> >> Hello,
> >>
> >> Please review the fix to the following issue:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8210633
> >>
> >> The proposed changeset is located at:
> >>
> >> http://cr.openjdk.java.net/~naoto/8210633/webrev.00/
> >>
> >> As the submitter pointed out, the overload method that takes Chronology
> >> needs to be overridden in the anonymous DateTimeTextProvider class.
> >>
> >> Naoto

From sean.coffey at oracle.com  Tue Sep 25 07:51:47 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 25 Sep 2018 08:51:47 +0100
Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents
 of empty JAR file
In-Reply-To: <712048a3-cf49-4824-8541-d689640f41b2@default>
References: <8a26c2a3-52ca-4d05-a102-2f6ec0341202@default>
 <712048a3-cf49-4824-8541-d689640f41b2@default>
Message-ID: <346339b4-6841-fc1c-b2ea-9c5f81206e0c@oracle.com>

This RFR should be removed from core-libs-dev. nio-dev is the correct 
mailing list.

The test needs to be fixed before that happens (and possibly the code also)

regards,
Sean.


On 25/09/2018 06:53, Deepak Kejriwal wrote:
> Hi,
>
> Gentle reminder for review below fix.
>
> Regards,
> Deepak
>
> -----Original Message-----
> From: Deepak Kejriwal
> Sent: Friday, September 21, 2018 3:26 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of empty JAR file
>
> Hi all,
>
>   
>
> Please help review the changes for JDK-8199776 to JDK8u:-
>
>   
>
> Master Bug: https://bugs.openjdk.java.net/browse/JDK-8199776
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8199776/webrev.00/
>
>   
>
> Background:-
>
> We have bug JDK-8197398 fixed in jdk 12 where Files.walkFileTree walk indefinitely while processing JAR file with "/" as a directory inside.
>
> Since code for zipfs in jdk8dev different compared to jdk 12, the fix is not exactly same.
>
>   
>
> Proposed fix:
>
> While iterating over the zip entries added a check to see if entry name is equal to "/" (absolute path). If the entry name is equal to "/" we don't add it to "inodes" map.
>
>   
>
> Regards,
>
> Deepak


From pallavi.sonal at oracle.com  Tue Sep 25 08:27:38 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Tue, 25 Sep 2018 01:27:38 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
Message-ID: <65120bb8-af2a-4144-a334-f1057c21fbf6@default>

Hi Stephen,
Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ? 

-----Original Message-----
From: Stephen Colebourne <scolebourne at joda.org> 
Sent: Sunday, September 23, 2018 12:36 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks

Can we change the docs to:

<p>
When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.

thanks
Stephen


On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>   http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>
> Thanks,
> Pallavi Sonal.
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Thursday, September 20, 2018 6:38 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> handle offsets
>
> Thanks for the update.
>
> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
> eg. a negative offset at MAX or a positive offset at MIN.
>
> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>
> thanks
> Stephen
>
>
> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> > Here is the updated webrev for review :
> > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
> >
> > Thanks,
> > Pallavi Sonal
> >
> > -----Original Message-----
> > From: Stephen Colebourne <scolebourne at joda.org>
> > Sent: Thursday, September 20, 2018 2:50 AM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> > handle offsets
> >
> > Thanks for looking at this.
> >
> > The proposed fix does not tackle the bug fully. The bug is that the 
> > spec says
> >
> > "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
> >
> > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
> >
> > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
> >
> > Furthermore, although there are numerous valid ISO-8601 ways of 
> > saying zero, this format uses dashes and colons in the date/time 
> > part, so
> > ISO-8601 restricts the offset to only those formats that include colons.
> >
> > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
> >
> > thanks
> > Stephen
> >
> >
> > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > >
> > > Hi,
> > >
> > > Please review the changes to the following issue:
> > >
> > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> > >
> > >
> > >
> > > The proposed fix is located at:
> > >
> > > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> > >
> > >
> > >
> > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> > >
> > >
> > >
> > > [1] https://en.wikipedia.org/wiki/ISO_8601
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Pallavi Sonal
> > >
> > >
> > >
> > >

From aph at redhat.com  Tue Sep 25 09:01:03 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 25 Sep 2018 10:01:03 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
Message-ID: <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>

On 09/24/2018 09:14 AM, Alan Bateman wrote:

> I'm not questioning the need to support NVM, instead I'm trying to
> see whether MappedByteBuffer is the right way to expose this in the
> standard API. Buffers were designed in JSR-51 with specific
> use-cases in mind but they are problematic for many off-heap cases
> as they aren't thread safe, are limited to 2GB, lack confinement,
> only support homogeneous data (no layout support).

I'm baffled by this assertion. It's true that the 2Gb limit is turning
into a real pain, but all of the rest are nothing to do with
ByteBuffers, which are just raw memory. Adding structure is something
that can be done by third-party libraries or by some future OpenJDK
API.

> So where does this leave us? If support for persistent memory is
> added to FileChannel.map as we've been discussing then it may not be
> too bad as the API surface is small. The API surface is just new map
> modes and a MappedByteBuffer::isPersistent method. The force method
> that specify a range is something useful to add to MBB anyway.

Yeah, that's right, it is. While something not yet planned might be an
alternative, even a better one, the purpose of our faster release
cadence is to "evolve the Java SE Platform and the JDK at a more rapid
pace, so that new features [can] be delivered in timelier
manner". This is timely; waiting for Panama to think of what might be
possible, not so much.

-- 
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  Tue Sep 25 09:06:00 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 25 Sep 2018 11:06:00 +0200
Subject: RFR: JDK-8211071: unpack.cpp fails to compile with statement has
 no effect [-Werror=unused-value]
In-Reply-To: <dd9fa3eb-c7ac-0c0f-2ddf-c3c5aec75bf9@redhat.com>
References: <dd9fa3eb-c7ac-0c0f-2ddf-c3c5aec75bf9@redhat.com>
Message-ID: <1654474A-1272-433C-9525-B0963E4298B3@oracle.com>


> 25 sep. 2018 kl. 10:21 skrev Roman Kennke <rkennke at redhat.com>:
> 
> Not sure this is the correct list. Please redirect as appropriate.

I believe core-libs is the appropriate place. Cc:d. 

> 
> Please review the following proposed change:
> 
> 
> There are 3 asserts in unpack.cpp which check only constants, and which
> the compiler rejects as 'has no effect' (in fastdebug builds). This
> seems to be caused by:
> 
> https://bugs.openjdk.java.net/browse/JDK-8211029
> 
> I propose to fix this by defining a STATIC_ASSERT which can evaluate and
> reject this at compile time:
> 
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8211071/webrev.00/

From a build perspective, this looks good. But please let someone from core-libs review also. 

> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8211071
> 
> It might be useful to define the STATIC_ASSERT in a more central place
> to be used elsewhere too. For example, there is a similar #define in
> Hotspot's debug.hpp

Unfortunately, we do not have a good place to share definitions like this across JDK libraries. :-( The need for that has struck me more than once. For some stuff, we mis-use jni.h. But it would definitely be out of line to add a STATIC_ASSERT there. 

/Magnus

> 
> Thanks, Roman
> 


From scolebourne at joda.org  Tue Sep 25 11:08:34 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 25 Sep 2018 12:08:34 +0100
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
Message-ID: <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>

I think it makes sense for both, although I was only considering
appendInstant() when I wrote it.
Stephen


On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Hi Stephen,
> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Sunday, September 23, 2018 12:36 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>
> Thanks
>
> Can we change the docs to:
>
> <p>
> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>
> thanks
> Stephen
>
>
> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
> >   http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
> >
> > Thanks,
> > Pallavi Sonal.
> >
> > -----Original Message-----
> > From: Stephen Colebourne <scolebourne at joda.org>
> > Sent: Thursday, September 20, 2018 6:38 PM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
> > handle offsets
> >
> > Thanks for the update.
> >
> > The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
> > eg. a negative offset at MAX or a positive offset at MIN.
> >
> > The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
> >
> > thanks
> > Stephen
> >
> >
> > On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > >
> > > Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> > > Here is the updated webrev for review :
> > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
> > >
> > > Thanks,
> > > Pallavi Sonal
> > >
> > > -----Original Message-----
> > > From: Stephen Colebourne <scolebourne at joda.org>
> > > Sent: Thursday, September 20, 2018 2:50 AM
> > > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
> > > handle offsets
> > >
> > > Thanks for looking at this.
> > >
> > > The proposed fix does not tackle the bug fully. The bug is that the
> > > spec says
> > >
> > > "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
> > >
> > > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
> > >
> > > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> > > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
> > >
> > > Furthermore, although there are numerous valid ISO-8601 ways of
> > > saying zero, this format uses dashes and colons in the date/time
> > > part, so
> > > ISO-8601 restricts the offset to only those formats that include colons.
> > >
> > > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
> > >
> > > thanks
> > > Stephen
> > >
> > >
> > > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please review the changes to the following issue:
> > > >
> > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> > > >
> > > >
> > > >
> > > > The proposed fix is located at:
> > > >
> > > > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> > > >
> > > >
> > > >
> > > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> > > >
> > > >
> > > >
> > > > [1] https://en.wikipedia.org/wiki/ISO_8601
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Pallavi Sonal
> > > >
> > > >
> > > >
> > > >

From christoph.langer at sap.com  Tue Sep 25 14:57:48 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 25 Sep 2018 14:57:48 +0000
Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
 permissions of the files
Message-ID: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>

Hi all,

I had asked for opinions regarding adding posix permission support to JDK?s zip handling libraries and tools [1]. Since I didn?t get clear ?no, you can?t do this? answers, I?m now concretely proposing some enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool.
I have reopened the long standing bug report (6194856) which had been set to ?Won?t fix? quite recently for this purpose.

Here are the technical details:
The ZIP format specifications by infozip and pkware ([2] and [3]) do not explicitly specify the handling of posix file permissions. But it seems to be common sense that if file attribute compatibility is set to ?Unix? in the upper byte of CEN field ?version made by?, the file permissions bits are stored in CEN field ?external file attributes?, byte 3 and 4. My changes try to honor this in the least obtrusive way. ??

The following changes are proposed:

java.util.zip.ZipEntry:
it will have an additional field ?posixPerms?. A value of -1 means ?no permission information?, positive values will contain the flag values.
There will be 2 new public methods to read/set the permission information:
                public Optional<Set<PosixFilePermission>> getPosixPermissions()
                public void setPosixPermissions(Set<PosixFilePermission> permissions)
The usage of type ?Optional? reflects that posix permissions are not necessarily present in a zip file
java.util.zip.ZipFile:
                it will have the capability to read the CEN fields and set posixPerms if available
java.util.zip.ZipOutputStream:
                it will store entries with associated posix permissions as unix type in the CEN, together with the bit mask for the permissions


jdk.jartool:
I propose to add and option "--preserve-posix" or short "-o" to honor the posix bits that may be stored inside zip/jar files. By default the option is not set and hence posix permissions are ignored. If the flag is set and the file system that the jar tool is running on supports posix, posix file permissions that exist in the file system will be stored in newly created/update archives or restored to the file system if such information is present in the archive.


jdk.zipfs:
                I added the capability for posix file permissions in the implementation. I decided to support PosixFileAttributes by subclassing ZipFileAttributes from this superclass as well as subclassing ZipFileAttributeView from PosixFileAttributeView. However, as PosixFileAttributes also include groups and owners, I would throw UnsupportedOperationExceptions in case of invoking methods to handle these attributes. But this approach seems to be most consistent with e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions.


java.nio.file.attribute.PosixFilePermissions:
                As this class presents a collection of static helpers, I added definitions for the posix file bit masks together with methods to convert between Sets of PosixFilePermission to bit masks containing the according switches and vice versa. These definitions could theoretically also be moved inside the java.util.zip or jdk.zipfs implementations where they wouldn?t be exposed as public APIs. However, in that case the code would probably need to be duplicated.


I?ve also created two jtreg testcases for both, java.util.zip and jdk.nio.zipfs.

The changes also contain a few further code cleanups.

Here are the links:
Bug: https://bugs.openjdk.java.net/browse/JDK-6194856
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/

I?ll write a CSR once there?s some substantial feedback to my endeavor.

Thanks in advance for reviewing/commenting.

Best regards
Christoph

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055375.html
[2] http://www.info-zip.org/doc/appnote-19970311-iz.zip
[3] https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT


From Alan.Bateman at oracle.com  Tue Sep 25 15:10:53 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Sep 2018 16:10:53 +0100
Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
References: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
Message-ID: <c3d87005-bb35-b23a-b702-e8fd2fa1e9c7@oracle.com>

On 25/09/2018 15:57, Langer, Christoph wrote:
>
> Hi all,
>
> I had asked for opinions regarding adding posix permission support to 
> JDK?s zip handling libraries and tools [1]. Since I didn?t get clear 
> ?no, you can?t do this? answers, I?m now concretely proposing some 
> enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool.
>
> I have reopened the long standing bug report (6194856) which had been 
> set to ?Won?t fix? quite recently for this purpose.
>
> Here are the technical details:
>
> The ZIP format specifications by infozip and pkware ([2] and [3]) do 
> not explicitly specify the handling of posix file permissions. But it 
> seems to be common sense that if file attribute compatibility is set 
> to ?Unix? in the upper byte of CEN field ?version made by?, the file 
> permissions bits are stored in CEN field ?external file attributes?, 
> byte 3 and 4. My changes try to honor this in the least obtrusive way. ??
>
> The following changes are proposed:
>
> java.util.zip.ZipEntry:
>
> it will have an additional field ?posixPerms?. A value of -1 means ?no 
> permission information?, positive values will contain the flag values.
>
> There will be 2 new public methods to read/set the permission information:
>
> ??????????????? public Optional<Set<PosixFilePermission>> 
> getPosixPermissions()
>
> ??????????????? public void 
> setPosixPermissions(Set<PosixFilePermission> permissions)
>
> The usage of type ?Optional? reflects that posix permissions are not 
> necessarily present in a zip file
>
> java.util.zip.ZipFile:
>
> ??????????????? it will have the capability to read the CEN fields and 
> set posixPerms if available
>
> java.util.zip.ZipOutputStream:
>
> ??????????????? it will store entries with associated posix 
> permissions as unix type in the CEN, together with the bit mask for 
> the permissions
>
> jdk.jartool:
>
> I propose to add and option "--preserve-posix" or short "-o" to honor 
> the posix bits that may be stored inside zip/jar files. By default the 
> option is not set and hence posix permissions are ignored. If the flag 
> is set and the file system that the jar tool is running on supports 
> posix, posix file permissions that exist in the file system will be 
> stored in newly created/update archives or restored to the file system 
> if such information is present in the archive.
>
> jdk.zipfs:
>
> ??????????????? I added the capability for posix file permissions in 
> the implementation. I decided to support PosixFileAttributes by 
> subclassing ZipFileAttributes from this superclass as well as 
> subclassing ZipFileAttributeView from PosixFileAttributeView. However, 
> as PosixFileAttributes also include groups and owners, I would throw 
> UnsupportedOperationExceptions in case of invoking methods to handle 
> these attributes. But this approach seems to be most consistent with 
> e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions.
>
> java.nio.file.attribute.PosixFilePermissions:
>
> ??????????????? As this class presents a collection of static helpers, 
> I added definitions for the posix file bit masks together with methods 
> to convert between Sets of PosixFilePermission to bit masks containing 
> the according switches and vice versa. These definitions could 
> theoretically also be moved inside the java.util.zip or jdk.zipfs 
> implementations where they wouldn?t be exposed as public APIs. 
> However, in that case the code would probably need to be duplicated.
>
> I?ve also created two jtreg testcases for both, java.util.zip and 
> jdk.nio.zipfs.
>
> The changes also contain a few further code cleanups.
>
> Here are the links:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6194856 
> <https://bugs.openjdk.java.net/browse/JDK-6194856>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/6194856.0/>
>
> I?ll write a CSR once there?s some substantial feedback to my endeavor.
>
>
I think this will require significant discussion as it was previously 
closed as WNF (as you found).

One initial comment is that you should be able to drop the API additions 
to PosxFilePermissions - I think all you need there translation from 
Set<PosixFilePermission> to internal values, it doesn't require bloating 
the API.

-Alan

From Roger.Riggs at oracle.com  Tue Sep 25 20:29:36 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 25 Sep 2018 16:29:36 -0400
Subject: [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
In-Reply-To: <400d4307-a80f-6aaa-20f8-e59af4d92e85@oracle.com>
References: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>
 <CACzrW9DiZDAoGXFMuJX1A_Rq=cNA5Lt121TF-1iyxakG=8FdpA@mail.gmail.com>
 <400d4307-a80f-6aaa-20f8-e59af4d92e85@oracle.com>
Message-ID: <3791937c-725d-5ace-4ece-33987c74678e@oracle.com>

Look fine Naoto.

Thanks, Roger


On 09/24/2018 04:39 PM, Naoto Sato wrote:
> Hi Stephen,
>
> Thank you for the review.
>
> On 9/22/18 11:57 PM, Stephen Colebourne wrote:
>> The change seems simple enough.
>> Does the test prove the change though? I thought the issue was with
>> months, not years?
>
> The jira issue refers to both. Added the month-of-year map testing as 
> well:
>
> http://cr.openjdk.java.net/~naoto/8210633/webrev.01/
>
> In fact, the submitter is trying to use this mapping for "Gannen" 
> (first year of the era) support for the upcoming Japanese new era 
> (May/2019), where formatting the first year would result in "??". 
> Currently, j.t.SimpleDateFormat can display this with 'y' pattern, as 
> it is calendar specific [1], DateTimeFormatter's 'y' is for digits only.
>
> Naoto
>
> [1] 
> https://docs.oracle.com/javase/10/docs/api/java/text/SimpleDateFormat.html#year
>
>> Stephen
>>
>>
>> On Thu, 20 Sep 2018 at 22:32, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8210633
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8210633/webrev.00/
>>>
>>> As the submitter pointed out, the overload method that takes Chronology
>>> needs to be overridden in the anonymous DateTimeTextProvider class.
>>>
>>> Naoto

-- 
Thanks, Roger


From pavel.rappo at oracle.com  Tue Sep 25 20:34:22 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 25 Sep 2018 21:34:22 +0100
Subject: Reactive Streams utility API
In-Reply-To: <CABY0rKPiKd6gTQ6eUrcq8WQPDTEMgzEm1=vWSaxfDOhbVkn+Yg@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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
 <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>
 <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.com>
 <CABY0rKPiKd6gTQ6eUrcq8WQPDTEMgzEm1=vWSaxfDOhbVkn+Yg@mail.gmail.com>
Message-ID: <4CFA6A61-4DCE-4C99-A879-D7AB4439020C@oracle.com>


> On 25 Sep 2018, at 05:33, James Roper <james at lightbend.com> wrote:
> 
> Hi Pavel,
> 
> <snip>
> 
> As for the MutexExecutor itself, that was mostly written by Viktor Klang, and I believe he wrote it based on his experience implementing similar constructs for Akka mailboxes. There is one major problem with it that I'm aware of - it's not fair on the underlying executor. If you submit tasks at an equal or higher rate than can be processed by a single thread, the executor will never return the thread it uses to the underlying executor. I don't think that's hard to fix - we could limit the number of sequential tasks it does on a thread before resubmitting to the underlying executor.
> 
> A slightly different incarnation of this problem is when each task invoked resubmits another task, for example, using the current reactive streams API, if I did ReactiveStreams.generate(() -> "foo").forEach(System.out::println), that is by design effectively an infinite loop that prints out foo, but being an asynchronous API it shouldn't actually be an infinite loop, it should return the thread back to the underlying executor at least periodically to allow that thread to be used for other tasks queued on the executor, but it doesn't do that.
> 
> But this issue (and some similar issues that may exist) we haven't begun to consider addressing, primarily because fixing it requires selecting some magic numbers for limits on work to do, and they can't be selected without some realistic benchmarks being created to tune them to, and we're just not ready to take this implementation to that level, it could change very significantly which would change all the assumptions before it's ready to be used.
> 

James, thanks for such a detailed explanation! Right now I'm mostly interested
in mechanics of this executor. I think this discussion deserves a separate
thread on concurrency-interest mailing list. What do you think? Once I've
started the thread there, I will get get back here with the link to it
(for the interested parties' convenience).

-Pavel


From lance.andersen at oracle.com  Tue Sep 25 23:10:03 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 25 Sep 2018 19:10:03 -0400
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
Message-ID: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>

Hi all:

JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules.

The diff for the change:
?????
s$ hg diff  src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java 
diff -r a6bdb6d5f167 src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
--- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 11:31:55 2018 -0700
+++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 17:32:48 2018 -0400
@@ -145,66 +145,6 @@
     }
 
     /**
-     * Invokes the supplied constructor, adding the provided protection domains
-     * to the invocation stack before invoking {@code Constructor::newInstance}.
-     * If no {@linkplain System#getSecurityManager() security manager} is present,
-     * or no domains are provided, then this method simply calls
-     * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor
-     * with privileges at the intersection of the current context and the provided
-     * protection domains.
-     *
-     * @param cons A constructor obtained from {@code
-     *        newConstructorForSerialization} or {@code
-     *        newConstructorForExternalization}.
-     * @param domains An array of protection domains that limit the privileges
-     *        with which the constructor is invoked. Can be {@code null}
-     *        or empty, in which case privileges are only limited by the
-     *        {@linkplain AccessController#getContext() current context}.
-     *
-     * @return A new object built from the provided constructor.
-     *
-     * @throws NullPointerException if {@code cons} is {@code null}.
-     * @throws InstantiationException if thrown by {@code cons.newInstance()}.
-     * @throws InvocationTargetException if thrown by {@code cons.newInstance()}.
-     * @throws IllegalAccessException if thrown by {@code cons.newInstance()}.
-     */
-    public final Object newInstanceForSerialization(Constructor<?> cons,
-                                                    ProtectionDomain[] domains)
-        throws InstantiationException, InvocationTargetException, IllegalAccessException
-    {
-        SecurityManager sm = System.getSecurityManager();
-        if (sm == null || domains == null || domains.length == 0) {
-            return cons.newInstance();
-        } else {
-            JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess();
-            PrivilegedAction<?> pea = () -> {
-                try {
-                    return cons.newInstance();
-                } catch (InstantiationException
-                         | InvocationTargetException
-                         | IllegalAccessException x) {
-                    throw new UndeclaredThrowableException(x);
-                }
-            }; // Can't use PrivilegedExceptionAction with jsa
-            try {
-                return jsa.doIntersectionPrivilege(pea,
-                           AccessController.getContext(),
-                           new AccessControlContext(domains));
-            } catch (UndeclaredThrowableException x) {
-                Throwable cause = x.getCause();
-                 if (cause instanceof InstantiationException)
-                    throw (InstantiationException) cause;
-                if (cause instanceof InvocationTargetException)
-                    throw (InvocationTargetException) cause;
-                if (cause instanceof IllegalAccessException)
-                    throw (IllegalAccessException) cause;
-                // not supposed to happen
-                throw x;
-            }
-        }
-    }
-
-    /**
      * Returns a direct MethodHandle for the {@code readObjectNoData} method on
      * a Serializable class.
      * The first argument of {@link MethodHandle#invoke} is the serializable
??????



Best
Lance
 <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 joe.darcy at oracle.com  Tue Sep 25 23:20:20 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 25 Sep 2018 16:20:20 -0700
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
In-Reply-To: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
References: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
Message-ID: <5BAAC2B4.5090403@oracle.com>

Hi Lance,

Looks fine; thanks,

-Joe

On 9/25/2018 4:10 PM, Lance Andersen wrote:
> Hi all:
>
> JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules.
>
> The diff for the change:
> ?????
> s$ hg diff  src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
> diff -r a6bdb6d5f167 src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
> --- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 11:31:55 2018 -0700
> +++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 17:32:48 2018 -0400
> @@ -145,66 +145,6 @@
>       }
>   
>       /**
> -     * Invokes the supplied constructor, adding the provided protection domains
> -     * to the invocation stack before invoking {@code Constructor::newInstance}.
> -     * If no {@linkplain System#getSecurityManager() security manager} is present,
> -     * or no domains are provided, then this method simply calls
> -     * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor
> -     * with privileges at the intersection of the current context and the provided
> -     * protection domains.
> -     *
> -     * @param cons A constructor obtained from {@code
> -     *        newConstructorForSerialization} or {@code
> -     *        newConstructorForExternalization}.
> -     * @param domains An array of protection domains that limit the privileges
> -     *        with which the constructor is invoked. Can be {@code null}
> -     *        or empty, in which case privileges are only limited by the
> -     *        {@linkplain AccessController#getContext() current context}.
> -     *
> -     * @return A new object built from the provided constructor.
> -     *
> -     * @throws NullPointerException if {@code cons} is {@code null}.
> -     * @throws InstantiationException if thrown by {@code cons.newInstance()}.
> -     * @throws InvocationTargetException if thrown by {@code cons.newInstance()}.
> -     * @throws IllegalAccessException if thrown by {@code cons.newInstance()}.
> -     */
> -    public final Object newInstanceForSerialization(Constructor<?> cons,
> -                                                    ProtectionDomain[] domains)
> -        throws InstantiationException, InvocationTargetException, IllegalAccessException
> -    {
> -        SecurityManager sm = System.getSecurityManager();
> -        if (sm == null || domains == null || domains.length == 0) {
> -            return cons.newInstance();
> -        } else {
> -            JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess();
> -            PrivilegedAction<?> pea = () -> {
> -                try {
> -                    return cons.newInstance();
> -                } catch (InstantiationException
> -                         | InvocationTargetException
> -                         | IllegalAccessException x) {
> -                    throw new UndeclaredThrowableException(x);
> -                }
> -            }; // Can't use PrivilegedExceptionAction with jsa
> -            try {
> -                return jsa.doIntersectionPrivilege(pea,
> -                           AccessController.getContext(),
> -                           new AccessControlContext(domains));
> -            } catch (UndeclaredThrowableException x) {
> -                Throwable cause = x.getCause();
> -                 if (cause instanceof InstantiationException)
> -                    throw (InstantiationException) cause;
> -                if (cause instanceof InvocationTargetException)
> -                    throw (InvocationTargetException) cause;
> -                if (cause instanceof IllegalAccessException)
> -                    throw (IllegalAccessException) cause;
> -                // not supposed to happen
> -                throw x;
> -            }
> -        }
> -    }
> -
> -    /**
>        * Returns a direct MethodHandle for the {@code readObjectNoData} method on
>        * a Serializable class.
>        * The first argument of {@link MethodHandle#invoke} is the serializable
> ??????
>
>
>
> Best
> Lance
>   <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 james at lightbend.com  Wed Sep 26 01:41:13 2018
From: james at lightbend.com (James Roper)
Date: Wed, 26 Sep 2018 11:41:13 +1000
Subject: Reactive Streams utility API
In-Reply-To: <4CFA6A61-4DCE-4C99-A879-D7AB4439020C@oracle.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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
 <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>
 <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.com>
 <CABY0rKPiKd6gTQ6eUrcq8WQPDTEMgzEm1=vWSaxfDOhbVkn+Yg@mail.gmail.com>
 <4CFA6A61-4DCE-4C99-A879-D7AB4439020C@oracle.com>
Message-ID: <CABY0rKNFK0zviVDR0pbHjyL7xsOf9XYN1QH2n3BYNU=ScE2gGw@mail.gmail.com>

Sounds good to me, I'll ping Viktor to make sure he sees it too.

On Wed, 26 Sep 2018 at 06:34, Pavel Rappo <pavel.rappo at oracle.com> wrote:

>
> > On 25 Sep 2018, at 05:33, James Roper <james at lightbend.com> wrote:
> >
> > Hi Pavel,
> >
> > <snip>
> >
> > As for the MutexExecutor itself, that was mostly written by Viktor
> Klang, and I believe he wrote it based on his experience implementing
> similar constructs for Akka mailboxes. There is one major problem with it
> that I'm aware of - it's not fair on the underlying executor. If you submit
> tasks at an equal or higher rate than can be processed by a single thread,
> the executor will never return the thread it uses to the underlying
> executor. I don't think that's hard to fix - we could limit the number of
> sequential tasks it does on a thread before resubmitting to the underlying
> executor.
> >
> > A slightly different incarnation of this problem is when each task
> invoked resubmits another task, for example, using the current reactive
> streams API, if I did ReactiveStreams.generate(() ->
> "foo").forEach(System.out::println), that is by design effectively an
> infinite loop that prints out foo, but being an asynchronous API it
> shouldn't actually be an infinite loop, it should return the thread back to
> the underlying executor at least periodically to allow that thread to be
> used for other tasks queued on the executor, but it doesn't do that.
> >
> > But this issue (and some similar issues that may exist) we haven't begun
> to consider addressing, primarily because fixing it requires selecting some
> magic numbers for limits on work to do, and they can't be selected without
> some realistic benchmarks being created to tune them to, and we're just not
> ready to take this implementation to that level, it could change very
> significantly which would change all the assumptions before it's ready to
> be used.
> >
>
> James, thanks for such a detailed explanation! Right now I'm mostly
> interested
> in mechanics of this executor. I think this discussion deserves a separate
> thread on concurrency-interest mailing list. What do you think? Once I've
> started the thread there, I will get get back here with the link to it
> (for the interested parties' convenience).
>
> -Pavel
>
>

-- 
*James Roper*
*Senior Developer, Office of the CTO*

Lightbend <https://www.lightbend.com/> ? Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>

From philipp.kunz at paratix.ch  Wed Sep 26 05:08:03 2018
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Wed, 26 Sep 2018 07:08:03 +0200
Subject: Patch for 6202130: java.util.jar.Attributes.writeMain() can't
 handle multi-byte chars
In-Reply-To: <5AEAB2A3.2050602@oracle.com>
References: <ec9706e3-6549-a3c5-68fa-815fdca9b9ca@paratix.ch>
 <fe880401-c836-a36b-36b9-446dec9a046b@paratix.ch>
 <5AEAB2A3.2050602@oracle.com>
Message-ID: <1537938483.2077.4.camel@paratix.ch>

Hi,

There are some comments in the source code like this:

 > XXX Need to handle UTF8 values and break up lines longer than 72 bytes

in Attributes.java on lines 299, 327, and 370. Bug 6202130 also suggests 
to add a test to show that the character set is fully supported before 
actually removing those comments.

Hence, I added such a test, see ValueUtfEncoding in attached patch, and 
it finds the complete utf character set supported correctly and that it 
has been so already before.

The comments in Attributes also say that lines longer than 72 bytes need 
to be broken. That is a different issue and has been already addressed 
and solved in bug 6372077 and is now tested in LineBreakLineWidth and 
therefore, that line break part of the comment is obsolete now as well 
with the exception of version headers ("Manifest-Version" or 
"Signature-Version") at least when taking strictly.

Version headers are not subject of bug 6202130 for which my patch 
intends to provide a fix and if only because multi-byte characters are 
not allowed in version headers and wasn't subject of 6372077 either 
which was about too short lines rather than too long ones. If I would 
change only the minimum I could argue was safe, there would have to 
remain a comment in Attributes.java on line 327 like

 > XXX Need to handle version headers longer than 72 bytes

but I guess that should probably better be represented as another bug 
rather than this style of comment if at all desired. There are some bugs 
concerning version headers and particularly the behavior of the 
manifests in their absence, among possibly others, 6910466, 4935610, 
4271239, 8196371 and 4256580 which have some relation but I haven't 
found one that really fits the 72 byte line length limit of version 
headers. Whether such a bug is created or found or not, it does not 
directly relate to the one I'm trying to fix here, 6202130.

If also the test is good I would assume that the comments can be 
removed now without actually changing the Manifest and Attributes 
implementation.

Regards,
Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6202130.patch
Type: text/x-patch
Size: 10465 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20180926/4b49b454/6202130-0001.patch>

From mandy.chung at oracle.com  Wed Sep 26 05:19:00 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 25 Sep 2018 22:19:00 -0700
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
In-Reply-To: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
References: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
Message-ID: <0fb723e4-2ded-d888-b8cd-8a51f9b54a4f@oracle.com>

The imports statement of jdk.internal.misc.SharedSecrets and 
JavaSecurityAccess can be removed.

Otherwise looks fine.

Mandy

On 9/25/18 4:10 PM, Lance Andersen wrote:
> Hi all:
>
> JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules.
>
> The diff for the change:
> ?????
> s$ hg diff  src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
> diff -r a6bdb6d5f167 src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
> --- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 11:31:55 2018 -0700
> +++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 17:32:48 2018 -0400
> @@ -145,66 +145,6 @@
>       }
>   
>       /**
> -     * Invokes the supplied constructor, adding the provided protection domains
> -     * to the invocation stack before invoking {@code Constructor::newInstance}.
> -     * If no {@linkplain System#getSecurityManager() security manager} is present,
> -     * or no domains are provided, then this method simply calls
> -     * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor
> -     * with privileges at the intersection of the current context and the provided
> -     * protection domains.
> -     *
> -     * @param cons A constructor obtained from {@code
> -     *        newConstructorForSerialization} or {@code
> -     *        newConstructorForExternalization}.
> -     * @param domains An array of protection domains that limit the privileges
> -     *        with which the constructor is invoked. Can be {@code null}
> -     *        or empty, in which case privileges are only limited by the
> -     *        {@linkplain AccessController#getContext() current context}.
> -     *
> -     * @return A new object built from the provided constructor.
> -     *
> -     * @throws NullPointerException if {@code cons} is {@code null}.
> -     * @throws InstantiationException if thrown by {@code cons.newInstance()}.
> -     * @throws InvocationTargetException if thrown by {@code cons.newInstance()}.
> -     * @throws IllegalAccessException if thrown by {@code cons.newInstance()}.
> -     */
> -    public final Object newInstanceForSerialization(Constructor<?> cons,
> -                                                    ProtectionDomain[] domains)
> -        throws InstantiationException, InvocationTargetException, IllegalAccessException
> -    {
> -        SecurityManager sm = System.getSecurityManager();
> -        if (sm == null || domains == null || domains.length == 0) {
> -            return cons.newInstance();
> -        } else {
> -            JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess();
> -            PrivilegedAction<?> pea = () -> {
> -                try {
> -                    return cons.newInstance();
> -                } catch (InstantiationException
> -                         | InvocationTargetException
> -                         | IllegalAccessException x) {
> -                    throw new UndeclaredThrowableException(x);
> -                }
> -            }; // Can't use PrivilegedExceptionAction with jsa
> -            try {
> -                return jsa.doIntersectionPrivilege(pea,
> -                           AccessController.getContext(),
> -                           new AccessControlContext(domains));
> -            } catch (UndeclaredThrowableException x) {
> -                Throwable cause = x.getCause();
> -                 if (cause instanceof InstantiationException)
> -                    throw (InstantiationException) cause;
> -                if (cause instanceof InvocationTargetException)
> -                    throw (InvocationTargetException) cause;
> -                if (cause instanceof IllegalAccessException)
> -                    throw (IllegalAccessException) cause;
> -                // not supposed to happen
> -                throw x;
> -            }
> -        }
> -    }
> -
> -    /**
>        * Returns a direct MethodHandle for the {@code readObjectNoData} method on
>        * a Serializable class.
>        * The first argument of {@link MethodHandle#invoke} is the serializable
> ??????
>
>
>
> Best
> Lance
>   <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 Alan.Bateman at oracle.com  Wed Sep 26 06:59:55 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Sep 2018 07:59:55 +0100
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
In-Reply-To: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
References: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
Message-ID: <d1fdcb25-5476-0279-9551-e65ae8d37583@oracle.com>

On 26/09/2018 00:10, Lance Andersen wrote:
> Hi all:
>
> JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules.
>
Way back, this was in the CORBA bridge. I checked the version in 
javaee/glassfish-corba and it doesn't seem to use this method so I think 
you are okay. If someone shows up with an important usage then it can be 
discussed - I think the only interesting thing is the intersection of 
the current and provided security domains.

-Alan

From christoph.langer at sap.com  Wed Sep 26 07:48:54 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 26 Sep 2018 07:48:54 +0000
Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <c3d87005-bb35-b23a-b702-e8fd2fa1e9c7@oracle.com>
References: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
 <c3d87005-bb35-b23a-b702-e8fd2fa1e9c7@oracle.com>
Message-ID: <cb3062caf80e4fd5b33febd44cf1dbcf@sap.com>

Hi Alan,

thanks for your initial comments.

> One initial comment is that you should be able to drop the API additions to
> PosxFilePermissions - I think all you need there translation from
> Set<PosixFilePermission> to internal values, it doesn't require bloating the
> API.

I agree, it doesn't feel right to bloat PosixFilePermissions with details needed for zip operations.

I now moved this coding to the ZipUtils classes. The only drawback is the duplication of the code but there's already quite some duplication of coding between java.util.zip and jdk.nio.zipfs.

Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.1/

Best regards
Christoph

From Alan.Bateman at oracle.com  Wed Sep 26 10:35:52 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Sep 2018 11:35:52 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
Message-ID: <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>

On 26/09/2018 09:44, Andrew Dinn wrote:
> :
>> If you (collectively) are aware of this and other limitations, then
>> sure, let's proceed with this JEP.
> Well, I'm very happy to proceed if Alan is in agreement. One thing he
> suggested in an earlier post was splitting off the functionality to
> create a persistent ByteBuffer into a separate method so as to avoid any
> issues if we have to deprecate this model at a alter date. I think
> that's a quite reasonable precaution and I'd be happy to propose an
> alternative API or let Alan suggest one. Perhaps Alan can comment?
>
I'm reasonably happy with the approach that we converged on to introduce 
new map modes and use the existing FileChannel.map method. Ideally new 
map modes wouldn't need to be exposed but you've looked into that (to my 
satisfaction at least). One detail that I think may need another 
iteration or two on is whether we need one or two modes. This will 
become clearer once the javadoc is fleshed out a bit further. It maybe 
that one new map mode, "SYNC" for example, that works with the existing 
READ_WRITE mode may be clearer and easier to specify. I think that would 
be consistent with how copy-on-write mappings are exposed with the 
PRIVATE mode. It also provides a 1-1 mapping to the underlying MAP_SYNC 
flag too.

As regards the bigger topic on what the right API is for "memory" then I 
don't think ByteBuffer is the right answer. You've touched on a few of 
the issues in your mail but there are bigger issues around thread safety 
and confinement, also the issue of the buffer position/limit that get in 
the way and the reason why several libraries use Unsafe. There isn't any 
concrete proposal or discussion to point at around splitting out this 
aspect of Project Panama. Stuart and I just pointing out that a better 
solution could emerge which could lead to have an alternative API to map 
a region of NVM as "memory" rather than a mapped byte buffer. If I were 
developing a file system backed by NVM then that is probably the raw API 
that I would want, not MBB.

As regards introducing an API that we could deprecate then that musing 
was about introducing a JDK-specific API. If MapMode were an interface 
then we could have introduce a JDK-specific map mode that wouldn't have 
required rev'ing the standard API. Introducing a completely separate map 
method in a JDK-specific module doesn't seem to be worth it as I think 
we can be confident that the proposed and possible-new.future approaches 
will not conflict.

-Alan

From adinn at redhat.com  Wed Sep 26 13:27:31 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 26 Sep 2018 14:27:31 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <27c9458d-7257-378a-4e3a-bd03402794be@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
Message-ID: <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>

Hi Alan,

On 26/09/18 11:35, Alan Bateman wrote:

> I'm reasonably happy with the approach that we converged on to introduce
> new map modes and use the existing FileChannel.map method. Ideally new
> map modes wouldn't need to be exposed but you've looked into that (to my
> satisfaction at least). One detail that I think may need another
> iteration or two on is whether we need one or two modes. This will
> become clearer once the javadoc is fleshed out a bit further. It maybe
> that one new map mode, "SYNC" for example, that works with the existing
> READ_WRITE mode may be clearer and easier to specify. I think that would
> be consistent with how copy-on-write mappings are exposed with the
> PRIVATE mode. It also provides a 1-1 mapping to the underlying MAP_SYNC
> flag too.

I'm not clear why we should only use one flag. The two flags I specified
reflect two independent use cases, one where data stored in an NVM
device is accessed read-only and another where it is accessed
read-write. Are you suggesting that the read-only case is redundant? I'm
not sure I agree. For example, a utility which might want to review the
state of persistent data while a service is off-line would really want
to pass flag READ_ONLY_PERSISTENT. Of course, it could employ
READ_WRITE_PERSISTENT (or equivalently, SYNC) and just not write the
data but, mutatis mutandis, that same argument would remove the case for
flag READ_ONLY.

> As regards the bigger topic on what the right API is for "memory" then I
> don't think ByteBuffer is the right answer. You've touched on a few of
> the issues in your mail but there are bigger issues around thread safety
> and confinement, also the issue of the buffer position/limit that get in
> the way and the reason why several libraries use Unsafe. There isn't any
> concrete proposal or discussion to point at around splitting out this
> aspect of Project Panama. Stuart and I just pointing out that a better
> solution could emerge which could lead to have an alternative API to map
> a region of NVM as "memory" rather than a mapped byte buffer. If I were
> developing a file system backed by NVM then that is probably the raw API
> that I would want, not MBB.

I really don't understand how thread safety comes into the argument
here. How is some other mechanism going to avoid the need for client
threads -- or, rather, the applications which create them them -- to
manage concurrent updates of NVM? Are you perhaps thinking of some form
of software transactional memory? I'm really struggling to understand
why you keep raising this point without any further detail to explain
how the lack of exclusion and synchronization primitives constitutes a
problem this API that can be bypassed by rolling some equivalent
alternative into another API.

Also, can you explain what you mean by confinement? (thread confinement?).

Also, I don't think I would label this API an attempt to develop a file
system. I think that's rather and overblown characterisation of what it
does. This is an attempt to provide an intermediate storage tier
somewhere between a file system and volatile memory to
create/access/update data across program runs, without incurring the
costs associated with implementing that sort of capability on top of
existing file system implementations.

The use of a byte array layout at the base level is indeed, as the
success of Unix/Linux/MS Windows file systems makes clear, a helpful way
of enabling a variety of application-defined data layouts to be
implemented on top of this storage tier. But I don't really see how that
makes this a file system.

> As regards introducing an API that we could deprecate then that musing
> was about introducing a JDK-specific API. If MapMode were an interface
> then we could have introduce a JDK-specific map mode that wouldn't have
> required rev'ing the standard API. Introducing a completely separate map
> method in a JDK-specific module doesn't seem to be worth it as I think
> we can be confident that the proposed and possible-new.future approaches
> will not conflict.
Ok, so no need for a change there then I guess.

I'm still not quite sure where this reply leaves the JEP though. Shall I
update the Risks and Assumptions section to include mention of
JDK-5029431 as suggested to Stuart? Is there anything else I can do to
progress things?

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 Sep 26 14:29:09 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 26 Sep 2018 14:29:09 +0000
Subject: [XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID
 after failing SetupI18nProps call [windows]
Message-ID: <VI1PR02MB43842C138735904D7C1FEF3193150@VI1PR02MB4384.eurprd02.prod.outlook.com>

Hello,   could you please review this small change   (windows only)   ?

Currently, the function   "getJavaIDFromLangID"    (located in windows java_props_md.c)
only does proper deallocations after a  successful call to the  function SetupI18nProps.  See

    if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT),
                   &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]), &(elems[4]))) {

   ......
        for (index = 0; index < 5; index++) {
            free(elems[index]);
        }


However a failing call (SetupI18nProps returning false) might still need deallocations,  because the function  SetupI18nProps can malloc memory in the failing case as well .
The change initializes   the   pointers  in  char * elems[5];
And later  frees them in case they are not NULL .

Webrev and bug :

http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webrev/

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


Best regards, Matthias

From lutz.schmidt at sap.com  Wed Sep 26 14:42:06 2018
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Wed, 26 Sep 2018 14:42:06 +0000
Subject: [CAUTION] [XS] RFR : 8211149: fix potential memleak in
 getJavaIDFromLangID after failing SetupI18nProps call [windows]
Message-ID: <268EF156-FFB2-45E2-8F3E-C62B34D06810@sap.com>

Hi Matthias,

your change looks good. Please note that I'm not a reviewer! 

I have a suggestion you might want to think about: 
Why don't you move the free-loop outside the if-else? Except for the NULL check, it's the same code in both branches. 

Thanks for fixing!
Lutz

?On 26.09.18, 16:30, "core-libs-dev on behalf of Baesken, Matthias" <core-libs-dev-bounces at openjdk.java.net on behalf of matthias.baesken at sap.com> wrote:

    Hello,   could you please review this small change   (windows only)   ?
    
    Currently, the function   "getJavaIDFromLangID"    (located in windows java_props_md.c)
    only does proper deallocations after a  successful call to the  function SetupI18nProps.  See
    
        if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT),
                       &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]), &(elems[4]))) {
    
       ......
            for (index = 0; index < 5; index++) {
                free(elems[index]);
            }
    
    
    However a failing call (SetupI18nProps returning false) might still need deallocations,  because the function  SetupI18nProps can malloc memory in the failing case as well .
    The change initializes   the   pointers  in  char * elems[5];
    And later  frees them in case they are not NULL .
    
    Webrev and bug :
    
    http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webrev/
    
    https://bugs.openjdk.java.net/browse/JDK-8211149
    
    
    Best regards, Matthias
    


From adinn at redhat.com  Wed Sep 26 08:44:04 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 26 Sep 2018 09:44:04 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
Message-ID: <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>

Hi Stuart,

On 26/09/18 03:19, Stuart Marks wrote:
> I've been starting to look at some of the buffer-related issues and I've
> been discussing this issue with Alan.

I'd be interested to hear more details if the discussion has gone far
enough for any of it to be aired online.

> On 9/25/18 2:01 AM, Andrew Haley wrote:
>> . . .
>> I'm baffled by this assertion. It's true that the 2Gb limit is turning
>> into a real pain, but all of the rest are nothing to do with
>> ByteBuffers, which are just raw memory. Adding structure is something
>> that can be done by third-party libraries or by some future OpenJDK
>> API.
> 
> If you look around Java SE for a public API to represent raw memory,
> then MappedByteBuffer is the obvious choice; there isn't any realistic
> alternative right now. By asking whether MBB is "the right way to
> expose" raw memory, I think Alan is really saying, is MBB the best API
> to use to expose raw memory in the long run? I think the answer is
> clearly No.
Sorry, it may well be my fault but it's not really clear to me. You
mention two issues below, buffer size limit and API verbosity.

I acknowledge the former is a problem but i) there is a proposal
(JDK-8180628, referred to in the JEP) to deal with this limitation by
adding extra methods that support the creation of larger buffers and use
of long indices and ii) there are existing Java libraries built over
ByteBuffer that overcome this issue (as Sandhya pointed out in a note
somewhere near this one). Sure, both of these remedies have limitations
which /might/ lead to problems but I don't see (yet, at least) that they
are manifestly unworkable.

As regards the latter issue, I am not really sure what you are
suggesting would be a better alternative to using ByteBuffer get and put
methods? Are you perhaps thinking of some way of overlaying a record (or
object?) structure over the mapped memory that might allow a compiler to
provide an equivalent to these ByteBuffer method calls as direct memory
loads and stores? Of course, a Java library built on top of this
proposal could provide a similar abstraction, although perhaps not with
as firm guarantees for compiler optimization and certainly not with the
possibility of direct language integration.

Copying might indeed be an issue but surely that depends on the type of
data being written, the library design and the way the client needs to
operate in order to use it (essentially on whether it can size in
advance a data area in which to write the contents direct vs build a
separate copy as distinct pieces and then serialize them).

Anyway, I hope the above explains why I'm not sure about your use of the
the words 'clearly' or (in a in a later comment) 'insurmountable'.
Perhaps more details of your conversation with Alan would help.

> There are, however, certain things that can be done with buffers in the
> short term to make things work better. For example, JDK-5029431 absolute
> bulk put/get methods. I suspect this will be quite helpful for the NVM
> case, and indeed it's been something that's been asked for repeatedly
> for quite some time.

Would it be enough to add a comment to the Risks and Assumptions of the
JEP to point out this limitation and the potential need to address it,
mentioning this specific JDK issue -- much as was done with JDK-8180628.

> If you (collectively) are aware of this and other limitations, then
> sure, let's proceed with this JEP.

Well, I'm very happy to proceed if Alan is in agreement. One thing he
suggested in an earlier post was splitting off the functionality to
create a persistent ByteBuffer into a separate method so as to avoid any
issues if we have to deprecate this model at a alter date. I think
that's a quite reasonable precaution and I'd be happy to propose an
alternative API or let Alan suggest one. Perhaps Alan can comment?

> Agree, "waiting for Panama" is certainly not something that anyone wants
> to do.
Yes, indeed, there are already several important use cases waiting in
the wings.

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 aph at redhat.com  Wed Sep 26 09:53:23 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 26 Sep 2018 10:53:23 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
Message-ID: <d073aa9e-0c80-35c0-7430-c6b5dbfd7ff9@redhat.com>

On 09/26/2018 09:44 AM, Andrew Dinn wrote:
> As regards the latter issue, I am not really sure what you are
> suggesting would be a better alternative to using ByteBuffer get and put
> methods? Are you perhaps thinking of some way of overlaying a record (or
> object?) structure over the mapped memory that might allow a compiler to
> provide an equivalent to these ByteBuffer method calls as direct memory
> loads and stores? Of course, a Java library built on top of this
> proposal could provide a similar abstraction, although perhaps not with
> as firm guarantees for compiler optimization and certainly not with the
> possibility of direct language integration.

Thinking about it some more, I guess that being able to say something
like

  aFoo.bar = n;

rather than

  aFoo.setBar(n);

is preferable, although common Java practice (and indeed good OOP
practice) is to provide getters and setters rather than directly
expose fields. I suppose one advantage of being able to use an object
structure is that the compiler can do better (type-based) alias
analysis, can track dead stores, etc. But from a language design
perspective, the fact that classes internally use direct field
accesses but expose a completely different get/set notation is
something of a linguistic wart.

[ The BETA language used a single notation, the pattern, for
assignment, method calls, and argument passing. Therefore, in BETA
there would be no API difference between the two exaples above. They'd
both be something like

  n -> aFoo.bar

Curiously, the first commercial licences for BETA were acquired by
Bill Joy and James Gosling, so they knew about this, but I suppose a
more C-like notation for Java was the right decision. The BETA
notation would have been too frightening for the target audience. :-) ]

-- 
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 sandhya.viswanathan at intel.com  Tue Sep 25 17:31:23 2018
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 25 Sep 2018 17:31:23 +0000
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF0F805@FMSMSX126.amr.corp.intel.com>

Hi Alan,

It looks like Apache HBASE also uses FileChannel map and MappedByteBuffer mechanism. The feature proposed by Andrew Dinn and Jonathan Halliday will be very useful for Big Data frameworks as well and help them to use NVM without a need to go to JNI. Copying HBASE experts Anoop and Ram to this thread.

Apache has API layers to overcome the 2GB limitation through MultiByteBuff class:
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/nio/MultiByteBuff.html
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/util/ByteBufferArray.html

Some example uses of ByteBuffer in HBASE today:
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/io/hfile/bucket/FileMmapEngine.html
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/io/ByteBuffInputStream.html
https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/ipc/ServerRpcConnection.ByteBuffByteInput.html

Best Regards,
Sandhya

-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Monday, September 24, 2018 1:15 AM
To: Andrew Dinn <adinn at redhat.com>; core-libs-dev at openjdk.java.net; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; Aundhe, Shirish <shirish.aundhe at intel.com>; Dohrmann, Steve <steve.dohrmann at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Deshpande, Vivek R <vivek.r.deshpande at intel.com>; Jonathan Halliday <jonathan.halliday at redhat.com>
Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 21/09/2018 16:44, Andrew Dinn wrote:
> Hi Alan,
>
> Thanks for the response and apologies for failing to notice you had
> posted it some days ago (doh!).
>
> Jonathan Halliday has already explained how Red Hat might want to use
> this API. Well, what he said, essentially! In particular, this model
> provides a way of ensuring that raw byte data is able to be persisted
> coherently from Java with the minimal possible overhead. It would be up
> to client code above this layer to implement structuring mechanisms for
> how those raw bytes get populated with data and to manage any associated
> issues regarding atomicity, consistency and isolation (i.e. to provide
> the A, C and I of ACID to this API's D).
>
> The main point of the JEP is to ensure that this such a performant base
> capability is available for known important cases where that is needed
> such as, for example, a transaction manager or a distributed cache. If
> equivalent middleware written in C can use persistent memory to bring
> the persistent storage tier nearer to the CPU and, hence, lower data
> durability overheads then we really need an equivalently performant
> option in Java or risk Java dropping out as a player in those middleware
> markets.
>
> I am glad to hear that other alternatives might be available and would
> be happy to consider them. However, I'm not sure that this means this
> option is not still desirable, especially if it is orthogonal to those
> other alternatives. Most importantly, this one has the advantage that we
> know it is ready to use and will provide benefits (we have already
> implemented a journaled transaction log over it with promising results
> and someone from our messaging team has already been looking into using
> it to persist log messages). Indeed, we also know we can use it to
> provide a base for supporting all the use cases addressed by Intel's
> libpmem and available to C programmers, e.g. a block store, simply by
> implementing Java client libraries that provide managed access to the
> persistent buffer along the same lines as the Intel C libraries.
>
> I'm afraid I am not familiar with Panama 'scopes' and 'pointers' so I
> can't really compare options here. Can you point me at any info that
> explains what those terms mean and how it might be possible to use them
> to access off-heap, persistent data.
>
I'm not questioning the need to support NVM, instead I'm trying to see 
whether MappedByteBuffer is the right way to expose this in the standard 
API. Buffers were designed in JSR-51 with specific use-cases in mind but 
they are problematic for many off-heap cases as they aren't thread safe, 
are limited to 2GB, lack confinement, only support homogeneous data (no 
layout support). At the same time, Project Panama (foreign branch in 
panama/dev) has the potential to provide the right API to work with 
memory. I see Jonathan's mail where he seems to be using object 
serialization so the solution on the table works for his use-case but it 
may not be the right solution for more general multi-threaded access to 
NVM. There is some interest in seeing whether this part of Project 
Panama could be advanced to address many of the cases where developers 
are resorting to using Unsafe today. There would of course need to be 
some integration with buffers too. There's no concrete proposal/JEP at 
this time, I'm just pointing out that many of the complaints about 
buffers that are really cases where it's the wrong API and the real need 
is something more fundamental.

So where does this leave us? If support for persistent memory is added 
to FileChannel.map as we've been discussing then it may not be too bad 
as the API surface is small. The API surface is just new map modes and a 
MappedByteBuffer::isPersistent method. The force method that specify a 
range is something useful to add to MBB anyway. If (and I hope when) 
there is support for memory regions or pointers then I could imagine 
re-visiting this so that there are alternative ways to get a memory 
region or pointer that is backed by NVM. If the timing were different 
then I think we'd skip the new map modes and we would be having a 
different discussion here. An alternative is course to create the mapped 
buffer via a JDK-specific API as that would be easier to deprecate and 
remove in the future if needed.

I'm interested to see if there is other input on this topic before it 
gets locked into extending the standard API.

-Alan.

From stuart.marks at oracle.com  Wed Sep 26 02:19:02 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 25 Sep 2018 19:19:02 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <ad813d34-3ebd-6f66-332a-06b9446367c0@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
Message-ID: <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>

Hi Andrew,

I've been starting to look at some of the buffer-related issues and I've been 
discussing this issue with Alan.

On 9/25/18 2:01 AM, Andrew Haley wrote:
> On 09/24/2018 09:14 AM, Alan Bateman wrote:
> 
>> I'm not questioning the need to support NVM, instead I'm trying to
>> see whether MappedByteBuffer is the right way to expose this in the
>> standard API. Buffers were designed in JSR-51 with specific
>> use-cases in mind but they are problematic for many off-heap cases
>> as they aren't thread safe, are limited to 2GB, lack confinement,
>> only support homogeneous data (no layout support).
> 
> I'm baffled by this assertion. It's true that the 2Gb limit is turning
> into a real pain, but all of the rest are nothing to do with
> ByteBuffers, which are just raw memory. Adding structure is something
> that can be done by third-party libraries or by some future OpenJDK
> API.

If you look around Java SE for a public API to represent raw memory, then 
MappedByteBuffer is the obvious choice; there isn't any realistic alternative 
right now. By asking whether MBB is "the right way to expose" raw memory, I 
think Alan is really saying, is MBB the best API to use to expose raw memory in 
the long run? I think the answer is clearly No.

However, that's not an argument against proceeding with MBB. Rather, it's 
setting expectations that MBB has limitations that impose some pain in the short 
term, that possibly can be worked around, but which in the long term may prove 
to be insurmountable.

For an example of something that might be "insurmountable", I'll use the 2GB 
limitation. Doing something to raise the limit is certainly possible. The 
question is, after retrofitting this into the API, whether the result will be 
something that people want to program with, and whether it will perform well 
enough. It might not.

Another example would be a library layered on top that provides structured 
access. It's certainly possible have such a library that will get the job done. 
However, the Buffer API necessarily requires certain operations to be 
implemented using multiple method calls, or it might require copying in some 
cases. Either of these might impose unacceptable overhead.

There are, however, certain things that can be done with buffers in the short 
term to make things work better. For example, JDK-5029431 absolute bulk put/get 
methods. I suspect this will be quite helpful for the NVM case, and indeed it's 
been something that's been asked for repeatedly for quite some time.

If you (collectively) are aware of this and other limitations, then sure, let's 
proceed with this JEP.

>> So where does this leave us? If support for persistent memory is
>> added to FileChannel.map as we've been discussing then it may not be
>> too bad as the API surface is small. The API surface is just new map
>> modes and a MappedByteBuffer::isPersistent method. The force method
>> that specify a range is something useful to add to MBB anyway.
> 
> Yeah, that's right, it is. While something not yet planned might be an
> alternative, even a better one, the purpose of our faster release
> cadence is to "evolve the Java SE Platform and the JDK at a more rapid
> pace, so that new features [can] be delivered in timelier
> manner". This is timely; waiting for Panama to think of what might be
> possible, not so much.

Agree, "waiting for Panama" is certainly not something that anyone wants to do.

s'marks

From Alan.Bateman at oracle.com  Wed Sep 26 16:00:43 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Sep 2018 17:00:43 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <df03ca64-d68a-ca8b-5309-395672ac7dcb@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
Message-ID: <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>

On 26/09/2018 14:27, Andrew Dinn wrote:
> :
> I really don't understand how thread safety comes into the argument
> here. How is some other mechanism going to avoid the need for client
> threads -- or, rather, the applications which create them them -- to
> manage concurrent updates of NVM? Are you perhaps thinking of some form
> of software transactional memory? I'm really struggling to understand
> why you keep raising this point without any further detail to explain
> how the lack of exclusion and synchronization primitives constitutes a
> problem this API that can be bypassed by rolling some equivalent
> alternative into another API.
The reason that we've mentioned it a few times is because it's a 
significant issue. If you have a byte buffer then you can't have 
different threads accessing different parts of the buffer at the same 
time, at least not with any of the relative get/put methods as they 
depend on the buffer position. Sure you can globally synchronize all 
operations but you'll likely want much finer granularity. This bugbear 
comes up periodically, particularly when using buffers for cases that 
they weren't really designed for. Stuart pointed out the lack of 
absolute bulk get/put operations which is something that I think will 
help some of these cases.

>
> Also, can you explain what you mean by confinement? (thread confinement?).
Yes, thread vs. global. I haven't been following Panama close enough to 
say how this is exposed in the API.


>
> Also, I don't think I would label this API an attempt to develop a file
> system. I think that's rather and overblown characterisation of what it
> does.
I think you may have mis-read my mail as was just picking another 
example where MBB would be problematic.


> :
> I'm still not quite sure where this reply leaves the JEP though. Shall I
> update the Risks and Assumptions section to include mention of
> JDK-5029431 as suggested to Stuart? Is there anything else I can do to
> progress things?
>
It wouldn't do any harm to have this section mention that an alternative 
that exposes a more memory centric API may be possible in the future.

-Alan

From Alan.Bateman at oracle.com  Wed Sep 26 16:14:25 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Sep 2018 17:14:25 +0100
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
Message-ID: <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>

On 26/09/2018 16:58, Alan Bateman wrote:
> On 26/09/2018 16:51, Andrew Haley wrote:
>> Java_java_io_Console_echo looks like this:
>>
>> JNIEXPORT jboolean JNICALL
>> Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on)
>> {
>> ???? DWORD fdwMode;
>> ???? jboolean old;
>> ???? ...
>> ???? old = (fdwMode & ENABLE_ECHO_INPUT);
>> ???? ...
>> ???? return old;
>> }
>>
>> It only works by accident. jboolean is an unsigned byte.
>> ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode &
>> ENABLE_ECHO_INPUT fits into the result, but only by accident. We
>> should do things properly and return a clean boolean.
>>
>> Note that the Windows version of the code is correct: I assume the
>> UNIX version is an oversight.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8211163
>> http://cr.openjdk.java.net/~aph/8211163/
>>
>> OK?
> Probably better to bring this to core-libs-dev as I think it's the 
> same issue as this thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054479.html 
>
>
> I can't see a conclusion (as in change-set) but Ichiroh's second mail 
> has the same patch as you.
>
Moving this to core-libs-dev as this is third time this has come up. The 
patch looks okay to me.

-Alan


From shade at redhat.com  Wed Sep 26 16:18:19 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 26 Sep 2018 18:18:19 +0200
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
Message-ID: <418cfe5d-0f2f-3a7c-b225-a2c51b23f8ec@redhat.com>

On 09/26/2018 06:14 PM, Alan Bateman wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8211163
>>> http://cr.openjdk.java.net/~aph/8211163/
>>>
>> Probably better to bring this to core-libs-dev as I think it's the same issue as this thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054479.html
>>
>> I can't see a conclusion (as in change-set) but Ichiroh's second mail has the same patch as you.
>>
> Moving this to core-libs-dev as this is third time this has come up. The patch looks okay to me.

Replying again here. Patch looks good.

-Aleksey




From enasser at in.ibm.com  Wed Sep 26 16:33:52 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Wed, 26 Sep 2018 16:33:52 +0000
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero from
 java.text.DecimalFormat.format()
Message-ID: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>

Hello,

In java.text.DecimalFormat.format(), there is a validation to check 
whether a number is negative zero or not and for that divide by zero is 
used to check for negative infinity which caused the ArithmeticException 
when SIGFPE is enabled in the system. Andrew has opened a bug on my 
behalf. Thank you Andrew.

The corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8211161. 

The webrev and stand alone test case is uploaded to 
http://cr.openjdk.java.net/~aleonard/8211161/. 
The recreate step is documented in the bug description.

I have tested the fix with the test cases of the following bugs and 
confirm that it is working.
https://bugs.java.com/view_bug.do?bug_id=4106658
https://bugs.java.com/view_bug.do?bug_id=4106667
https://bugs.java.com/view_bug.do?bug_id=4147706

I did not add any new jtreg test for the current issue as it is not 
functional. Hope that is fine.

Kindly request you to review and comment.

Thank you,
Nasser Ebrahim


From aph at redhat.com  Wed Sep 26 16:35:27 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 26 Sep 2018 17:35:27 +0100
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
Message-ID: <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>

On 09/26/2018 05:14 PM, Alan Bateman wrote:
> Moving this to core-libs-dev as this is third time this has come up. The 
> patch looks okay to me.

Yeah. I think we've spent enough time thinking about this now.

-- 
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 naoto.sato at oracle.com  Wed Sep 26 16:49:05 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 26 Sep 2018 09:49:05 -0700
Subject: [XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID
 after failing SetupI18nProps call [windows]
In-Reply-To: <VI1PR02MB43842C138735904D7C1FEF3193150@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <VI1PR02MB43842C138735904D7C1FEF3193150@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <4f53658d-1014-03e9-f5cb-3d1c41ae246c@oracle.com>

Hi Matthias,

Thank you for fixing this. Here are my comments:

- You could merge the similar for loop at 191-193, and place the loop at 
the very end before it returns.

- Please expand the if block body at line 196.

Naoto

On 9/26/18 7:29 AM, Baesken, Matthias wrote:
> Hello,   could you please review this small change   (windows only)   ?
> 
> Currently, the function   "getJavaIDFromLangID"    (located in windows java_props_md.c)
> only does proper deallocations after a  successful call to the  function SetupI18nProps.  See
> 
>      if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT),
>                     &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]), &(elems[4]))) {
> 
>     ......
>          for (index = 0; index < 5; index++) {
>              free(elems[index]);
>          }
> 
> 
> However a failing call (SetupI18nProps returning false) might still need deallocations,  because the function  SetupI18nProps can malloc memory in the failing case as well .
> The change initializes   the   pointers  in  char * elems[5];
> And later  frees them in case they are not NULL .
> 
> Webrev and bug :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webrev/
> 
> https://bugs.openjdk.java.net/browse/JDK-8211149
> 
> 
> Best regards, Matthias
> 

From joe.darcy at oracle.com  Wed Sep 26 16:59:23 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 26 Sep 2018 09:59:23 -0700
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero
 from java.text.DecimalFormat.format()
In-Reply-To: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
Message-ID: <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>

Hello,

It may be reasonable to replace a divide by zero with check for a 
floating-point -0.0 with a bit-level check, but the stated motivation is 
not reasonable.

The Java platform requires that floating-point divide by zero return an 
infinity (or NaN as the case may be) and it is *incorrect* and 
non-conformant to throw an ArithmeticException in that case. Such 
behavior violates the language the JVM specs.

Cheers,

-Joe


On 9/26/2018 9:33 AM, Nasser Ebrahim wrote:
> Hello,
>
> In java.text.DecimalFormat.format(), there is a validation to check
> whether a number is negative zero or not and for that divide by zero is
> used to check for negative infinity which caused the ArithmeticException
> when SIGFPE is enabled in the system. Andrew has opened a bug on my
> behalf. Thank you Andrew.
>
> The corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8211161.
>
> The webrev and stand alone test case is uploaded to
> http://cr.openjdk.java.net/~aleonard/8211161/.
> The recreate step is documented in the bug description.
>
> I have tested the fix with the test cases of the following bugs and
> confirm that it is working.
> https://bugs.java.com/view_bug.do?bug_id=4106658
> https://bugs.java.com/view_bug.do?bug_id=4106667
> https://bugs.java.com/view_bug.do?bug_id=4147706
>
> I did not add any new jtreg test for the current issue as it is not
> functional. Hope that is fine.
>
> Kindly request you to review and comment.
>
> Thank you,
> Nasser Ebrahim
>


From lance.andersen at oracle.com  Wed Sep 26 17:01:55 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 26 Sep 2018 13:01:55 -0400
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
In-Reply-To: <0fb723e4-2ded-d888-b8cd-8a51f9b54a4f@oracle.com>
References: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
 <0fb723e4-2ded-d888-b8cd-8a51f9b54a4f@oracle.com>
Message-ID: <527FB28A-E78C-45EC-99E7-6365668336B6@oracle.com>


> On Sep 26, 2018, at 1:19 AM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> The imports statement of jdk.internal.misc.SharedSecrets and JavaSecurityAccess can be removed.

Thank you Mandy,  thought I clicked to remove unused imports in netbeans but guess I did not.  Here is the revised diff

????
$ hg diff src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
diff -r e1368526699d src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
--- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Wed Sep 26 06:26:54 2018 +0800
+++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Wed Sep 26 12:41:11 2018 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 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
@@ -29,14 +29,9 @@
 import java.lang.invoke.MethodHandle;
 import java.lang.reflect.Constructor;
 import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.UndeclaredThrowableException;
-import java.security.AccessControlContext;
 import java.security.AccessController;
 import java.security.Permission;
-import java.security.ProtectionDomain;
 import java.security.PrivilegedAction;
-import jdk.internal.misc.SharedSecrets;
-import jdk.internal.misc.JavaSecurityAccess;
 
 /**
  * ReflectionFactory supports custom serialization.
@@ -145,66 +140,6 @@
     }
 
     /**
-     * Invokes the supplied constructor, adding the provided protection domains
-     * to the invocation stack before invoking {@code Constructor::newInstance}.
-     * If no {@linkplain System#getSecurityManager() security manager} is present,
-     * or no domains are provided, then this method simply calls
-     * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor
-     * with privileges at the intersection of the current context and the provided
-     * protection domains.
-     *
-     * @param cons A constructor obtained from {@code
-     *        newConstructorForSerialization} or {@code
-     *        newConstructorForExternalization}.
-     * @param domains An array of protection domains that limit the privileges
-     *        with which the constructor is invoked. Can be {@code null}
-     *        or empty, in which case privileges are only limited by the
-     *        {@linkplain AccessController#getContext() current context}.
-     *
-     * @return A new object built from the provided constructor.
-     *
-     * @throws NullPointerException if {@code cons} is {@code null}.
-     * @throws InstantiationException if thrown by {@code cons.newInstance()}.
-     * @throws InvocationTargetException if thrown by {@code cons.newInstance()}.
-     * @throws IllegalAccessException if thrown by {@code cons.newInstance()}.
-     */
-    public final Object newInstanceForSerialization(Constructor<?> cons,
-                                                    ProtectionDomain[] domains)
-        throws InstantiationException, InvocationTargetException, IllegalAccessException
-    {
-        SecurityManager sm = System.getSecurityManager();
-        if (sm == null || domains == null || domains.length == 0) {
-            return cons.newInstance();
-        } else {
-            JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess();
-            PrivilegedAction<?> pea = () -> {
-                try {
-                    return cons.newInstance();
-                } catch (InstantiationException
-                         | InvocationTargetException
-                         | IllegalAccessException x) {
-                    throw new UndeclaredThrowableException(x);
-                }
-            }; // Can't use PrivilegedExceptionAction with jsa
-            try {
-                return jsa.doIntersectionPrivilege(pea,
-                           AccessController.getContext(),
-                           new AccessControlContext(domains));
-            } catch (UndeclaredThrowableException x) {
-                Throwable cause = x.getCause();
-                 if (cause instanceof InstantiationException)
-                    throw (InstantiationException) cause;
-                if (cause instanceof InvocationTargetException)
-                    throw (InvocationTargetException) cause;
-                if (cause instanceof IllegalAccessException)
-                    throw (IllegalAccessException) cause;
-                // not supposed to happen
-                throw x;
-            }
-        }
-    }
-
-    /**
      * Returns a direct MethodHandle for the {@code readObjectNoData} method on
      * a Serializable class.
      * The first argument of {@link MethodHandle#invoke} is the serializable
?????

Local build went fine.  Mach5 is running again for an additional sanity check

Best
Lance
> 
> Otherwise looks fine.
> 
> Mandy
> 
> On 9/25/18 4:10 PM, Lance Andersen wrote:
>> Hi all:
>> 
>> JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules.
>> 
>> The diff for the change:
>> ?????
>> s$ hg diff  src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java 
>> diff -r a6bdb6d5f167 src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java
>> --- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 11:31:55 2018 -0700
>> +++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java	Tue Sep 25 17:32:48 2018 -0400
>> @@ -145,66 +145,6 @@
>>      }
>>  
>>      /**
>> -     * Invokes the supplied constructor, adding the provided protection domains
>> -     * to the invocation stack before invoking {@code Constructor::newInstance}.
>> -     * If no {@linkplain System#getSecurityManager() security manager} is present,
>> -     * or no domains are provided, then this method simply calls
>> -     * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor
>> -     * with privileges at the intersection of the current context and the provided
>> -     * protection domains.
>> -     *
>> -     * @param cons A constructor obtained from {@code
>> -     *        newConstructorForSerialization} or {@code
>> -     *        newConstructorForExternalization}.
>> -     * @param domains An array of protection domains that limit the privileges
>> -     *        with which the constructor is invoked. Can be {@code null}
>> -     *        or empty, in which case privileges are only limited by the
>> -     *        {@linkplain AccessController#getContext() current context}.
>> -     *
>> -     * @return A new object built from the provided constructor.
>> -     *
>> -     * @throws NullPointerException if {@code cons} is {@code null}.
>> -     * @throws InstantiationException if thrown by {@code cons.newInstance()}.
>> -     * @throws InvocationTargetException if thrown by {@code cons.newInstance()}.
>> -     * @throws IllegalAccessException if thrown by {@code cons.newInstance()}.
>> -     */
>> -    public final Object newInstanceForSerialization(Constructor<?> cons,
>> -                                                    ProtectionDomain[] domains)
>> -        throws InstantiationException, InvocationTargetException, IllegalAccessException
>> -    {
>> -        SecurityManager sm = System.getSecurityManager();
>> -        if (sm == null || domains == null || domains.length == 0) {
>> -            return cons.newInstance();
>> -        } else {
>> -            JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess();
>> -            PrivilegedAction<?> pea = () -> {
>> -                try {
>> -                    return cons.newInstance();
>> -                } catch (InstantiationException
>> -                         | InvocationTargetException
>> -                         | IllegalAccessException x) {
>> -                    throw new UndeclaredThrowableException(x);
>> -                }
>> -            }; // Can't use PrivilegedExceptionAction with jsa
>> -            try {
>> -                return jsa.doIntersectionPrivilege(pea,
>> -                           AccessController.getContext(),
>> -                           new AccessControlContext(domains));
>> -            } catch (UndeclaredThrowableException x) {
>> -                Throwable cause = x.getCause();
>> -                 if (cause instanceof InstantiationException)
>> -                    throw (InstantiationException) cause;
>> -                if (cause instanceof InvocationTargetException)
>> -                    throw (InvocationTargetException) cause;
>> -                if (cause instanceof IllegalAccessException)
>> -                    throw (IllegalAccessException) cause;
>> -                // not supposed to happen
>> -                throw x;
>> -            }
>> -        }
>> -    }
>> -
>> -    /**
>>       * Returns a direct MethodHandle for the {@code readObjectNoData} method on
>>       * a Serializable class.
>>       * The first argument of {@link MethodHandle#invoke} is the serializable
>> ??????
>> 
>> 
>> 
>> Best
>> Lance
>>  <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> <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> <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 

 <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 takiguc at linux.vnet.ibm.com  Wed Sep 26 17:07:07 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 27 Sep 2018 02:07:07 +0900
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
Message-ID: <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>

Hello.

Sorry for bad operation.
In case of s390x platform, this issue was fixed by JDK-8209637.
https://bugs.openjdk.java.net/browse/JDK-8209637

If you could recreate this issue, please check JVM side also.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-09-27 01:35, Andrew Haley wrote:
> On 09/26/2018 05:14 PM, Alan Bateman wrote:
>> Moving this to core-libs-dev as this is third time this has come up. 
>> The
>> patch looks okay to me.
> 
> Yeah. I think we've spent enough time thinking about this now.


From xueming.shen at oracle.com  Wed Sep 26 17:17:33 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 26 Sep 2018 10:17:33 -0700
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does
 not return a clean boolean
In-Reply-To: <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
Message-ID: <5BABBF2D.7050509@oracle.com>

+1

On 9/26/18, 9:14 AM, Alan Bateman wrote:
> On 26/09/2018 16:58, Alan Bateman wrote:
>> On 26/09/2018 16:51, Andrew Haley wrote:
>>> Java_java_io_Console_echo looks like this:
>>>
>>> JNIEXPORT jboolean JNICALL
>>> Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on)
>>> {
>>>      DWORD fdwMode;
>>>      jboolean old;
>>>      ...
>>>      old = (fdwMode & ENABLE_ECHO_INPUT);
>>>      ...
>>>      return old;
>>> }
>>>
>>> It only works by accident. jboolean is an unsigned byte.
>>> ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode &
>>> ENABLE_ECHO_INPUT fits into the result, but only by accident. We
>>> should do things properly and return a clean boolean.
>>>
>>> Note that the Windows version of the code is correct: I assume the
>>> UNIX version is an oversight.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8211163
>>> http://cr.openjdk.java.net/~aph/8211163/
>>>
>>> OK?
>> Probably better to bring this to core-libs-dev as I think it's the 
>> same issue as this thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054479.html 
>>
>>
>> I can't see a conclusion (as in change-set) but Ichiroh's second mail 
>> has the same patch as you.
>>
> Moving this to core-libs-dev as this is third time this has come up. 
> The patch looks okay to me.
>
> -Alan
>


From rkennke at redhat.com  Wed Sep 26 17:24:25 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 26 Sep 2018 19:24:25 +0200
Subject: RFR: JDK-8211071: unpack.cpp fails to compile with statement has
 no effect [-Werror=unused-value]
In-Reply-To: <1654474A-1272-433C-9525-B0963E4298B3@oracle.com>
References: <dd9fa3eb-c7ac-0c0f-2ddf-c3c5aec75bf9@redhat.com>
 <1654474A-1272-433C-9525-B0963E4298B3@oracle.com>
Message-ID: <bb6d1c5f-a023-f8e9-6733-b68dc146ebbb@redhat.com>

Ping core-libs?

Roman

Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
> 
>> 25 sep. 2018 kl. 10:21 skrev Roman Kennke <rkennke at redhat.com>:
>>
>> Not sure this is the correct list. Please redirect as appropriate.
> 
> I believe core-libs is the appropriate place. Cc:d. 
> 
>>
>> Please review the following proposed change:
>>
>>
>> There are 3 asserts in unpack.cpp which check only constants, and which
>> the compiler rejects as 'has no effect' (in fastdebug builds). This
>> seems to be caused by:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8211029
>>
>> I propose to fix this by defining a STATIC_ASSERT which can evaluate and
>> reject this at compile time:
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8211071/webrev.00/
> 
> From a build perspective, this looks good. But please let someone from core-libs review also. 
> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8211071
>>
>> It might be useful to define the STATIC_ASSERT in a more central place
>> to be used elsewhere too. For example, there is a similar #define in
>> Hotspot's debug.hpp
> 
> Unfortunately, we do not have a good place to share definitions like this across JDK libraries. :-( The need for that has struck me more than once. For some stuff, we mis-use jni.h. But it would definitely be out of line to add a STATIC_ASSERT there. 
> 
> /Magnus
> 
>>
>> Thanks, Roman
>>
> 


From raffaello.giulietti at gmail.com  Wed Sep 26 17:39:44 2018
From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com)
Date: Wed, 26 Sep 2018 19:39:44 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect
 results
Message-ID: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>

Hi,

the current specification of Double.toString(double) is not precise
enough to uniquely determine the resulting String. It leaves leeway for
interpretation, thus potentially allowing implementations to return
slightly different results, even from one release to the next [1].

In addition, as the bug description points out, the current
implementation does not even always meet its own specification, leading
to results that are sometimes longer than needed.

To address and overcome both issues, a new specification in the form of
Javadoc associated to Double.toString(double) and Float.toString(float)
is proposed, along with a clean-room re-implementation.

The intent of the specification is to explicitly separate the
determination of the unique decimal number to represent the floating
point argument (double/float) from its formatting as a String.

The clean-room implementation enjoys the following properties:
* No objects at all are instantiated except for the resulting String and
its backing storage.
* Only arithmetic on longs/ints is performed.
* The decimal selection algorithm performs at most one division on longs
per conversion and is loop-free.
* The digits extraction algorithm is totally division-free.
* None of the anomalies described in the bug report have been observed.
* The new Double.toString(double) speedup with respect to the current
implementation, according to jmh, is better than 13x when measured over
bitwise uniformly distributed random samples.
* In the case of Float.toString(float), *all* results of the 2^32 float
values have been extensively tested to meet the specification.
* In the case of Double.toString(double), as it is infeasible to test
all results, several billions of random doubles have been extensively
tested.

Since there's a change in the specification, according to my sponsor and
the formalities it has to undergo a CSR.



The submitted code contains both the changes to the current
implementation and extensive jtreg tests.



While I've struggled to keep the code within the 80 chars/line limit,
mercurial still generates longer lines. Thus, to avoid possible problems
with the email systems, the code is submitted both inline and as an
attachment. Hope at least one copy makes its way without errors.


Greetings
Raffaello


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



# HG changeset patch
# User lello
# Date 1537948169 -7200
#      Wed Sep 26 09:49:29 2018 +0200
# Node ID 6bd9d2c45440c578b93d2f07e5eaea73928be4d5
# Parent  5f931e3e7a63b550d832d2624db32033b875c720
Patches to fix JDK-4511638

diff --git a/src/java.base/share/classes/java/lang/Double.java
b/src/java.base/share/classes/java/lang/Double.java
--- a/src/java.base/share/classes/java/lang/Double.java
+++ b/src/java.base/share/classes/java/lang/Double.java
@@ -25,6 +25,7 @@

 package java.lang;

+import jdk.internal.math.DoubleToDecimal;
 import jdk.internal.math.FloatingDecimal;
 import jdk.internal.math.DoubleConsts;
 import jdk.internal.HotSpotIntrinsicCandidate;
@@ -139,69 +140,108 @@
     public static final Class<Double>   TYPE = (Class<Double>)
Class.getPrimitiveClass("double");

     /**
-     * Returns a string representation of the {@code double}
-     * argument. All characters mentioned below are ASCII characters.
-     * <ul>
-     * <li>If the argument is NaN, the result is the string
-     *     "{@code NaN}".
-     * <li>Otherwise, the result is a string that represents the sign and
-     * magnitude (absolute value) of the argument. If the sign is negative,
-     * the first character of the result is '{@code -}'
-     * ({@code '\u005Cu002D'}); if the sign is positive, no sign character
-     * appears in the result. As for the magnitude <i>m</i>:
+     * Returns a string rendering of the {@code double} argument.
+     *
+     * <p>The characters of the result are all drawn from the ASCII set.
      * <ul>
-     * <li>If <i>m</i> is infinity, it is represented by the characters
-     * {@code "Infinity"}; thus, positive infinity produces the result
-     * {@code "Infinity"} and negative infinity produces the result
-     * {@code "-Infinity"}.
+     *     <li> Any NaN, whether quiet or signaling, is rendered
symbolically
+     *     as {@code "NaN"}, regardless of the sign bit.
+     *     <li> The infinities +&infin; and -&infin; are rendered as
+     *     {@code "Infinity"} and {@code "-Infinity"}, respectively.
+     *     <li> The positive and negative zeroes are rendered as
+     *     {@code "0.0"} and {@code "-0.0"}, respectively.
+     *     <li> Otherwise {@code v} is finite and non-zero.
+     *     It is rendered in two stages:
+     *     <ul>
+     *         <li> <em>Selection of a decimal</em>: A well-specified
non-zero
+     *         decimal <i>d</i> is selected to represent {@code v}.
+     *         <li> <em>Formatting as a string</em>: The decimal
<i>d</i> is
+     *         formatted as a string, either in plain or in computerized
+     *         scientific notation, depending on its value.
+     *     </ul>
+     * </ul>
      *
-     * <li>If <i>m</i> is zero, it is represented by the characters
-     * {@code "0.0"}; thus, negative zero produces the result
-     * {@code "-0.0"} and positive zero produces the result
-     * {@code "0.0"}.
-     *
-     * <li>If <i>m</i> is greater than or equal to 10<sup>-3</sup> but less
-     * than 10<sup>7</sup>, then it is represented as the integer part of
-     * <i>m</i>, in decimal form with no leading zeroes, followed by
-     * '{@code .}' ({@code '\u005Cu002E'}), followed by one or
-     * more decimal digits representing the fractional part of <i>m</i>.
+     * <p>The selected decimal <i>d</i> has a length <i>n</i> if it can be
+     * written as <i>d</i> = <i>c</i>&middot;10<sup><i>q</i></sup> for some
+     * integers <i>q</i> and <i>c</i> meeting 10<sup><i>n</i>-1</sup> &le;
+     * |<i>c</i>| &lt; 10<sup><i>n</i></sup>. It has all the following
+     * properties:
+     * <ul>
+     *     <li> It rounds to {@code v} according to the usual
round-to-closest
+     *     rule of IEEE 754 floating-point arithmetic.
+     *     <li> Among the decimals above, it has a length of 2 or more.
+     *     <li> Among all such decimals, it is one of those with the
shortest
+     *     length.
+     *     <li> Among the latter ones, it is the one closest to {@code
v}. Or
+     *     if there are two that are equally close to {@code v}, it is
the one
+     *     whose least significant digit is even.
+     * </ul>
+     * More formally, let <i>d'</i> =
<i>c'</i>&middot;10<sup><i>q'</i></sup>
+     * &ne; <i>d</i> be any other decimal that rounds to {@code v}
according to
+     * IEEE 754 and of a length <i>n'</i>. Then:
+     * <ul>
+     *     <li> either <i>n'</i> = 1, thus <i>d'</i> is too short;
+     *     <li> or <i>n'</i> &gt; <i>n</i>, thus <i>d'</i> is too long;
+     *     <li> or <i>n'</i> = <i>n</i> and
+     *     <ul>
+     *         <li> either |<i>d</i> - {@code v}| &lt; |<i>d'</i> -
{@code v}|:
+     *         thus <i>d'</i> is farther from {@code v};
+     *         <li> or |<i>d</i> - {@code v}| = |<i>d'</i> - {@code v}| and
+     *         <i>c</i> is even while <i>c'</i> is odd
+     *     </ul>
+     * </ul>
      *
-     * <li>If <i>m</i> is less than 10<sup>-3</sup> or greater than or
-     * equal to 10<sup>7</sup>, then it is represented in so-called
-     * "computerized scientific notation." Let <i>n</i> be the unique
-     * integer such that 10<sup><i>n</i></sup> &le; <i>m</i> {@literal <}
-     * 10<sup><i>n</i>+1</sup>; then let <i>a</i> be the
-     * mathematically exact quotient of <i>m</i> and
-     * 10<sup><i>n</i></sup> so that 1 &le; <i>a</i> {@literal <} 10. The
-     * magnitude is then represented as the integer part of <i>a</i>,
-     * as a single decimal digit, followed by '{@code .}'
-     * ({@code '\u005Cu002E'}), followed by decimal digits
-     * representing the fractional part of <i>a</i>, followed by the
-     * letter '{@code E}' ({@code '\u005Cu0045'}), followed
-     * by a representation of <i>n</i> as a decimal integer, as
-     * produced by the method {@link Integer#toString(int)}.
-     * </ul>
-     * </ul>
-     * How many digits must be printed for the fractional part of
-     * <i>m</i> or <i>a</i>? There must be at least one digit to represent
-     * the fractional part, and beyond that as many, but only as many, more
-     * digits as are needed to uniquely distinguish the argument value from
-     * adjacent values of type {@code double}. That is, suppose that
-     * <i>x</i> is the exact mathematical value represented by the decimal
-     * representation produced by this method for a finite nonzero argument
-     * <i>d</i>. Then <i>d</i> must be the {@code double} value nearest
-     * to <i>x</i>; or if two {@code double} values are equally close
-     * to <i>x</i>, then <i>d</i> must be one of them and the least
-     * significant bit of the significand of <i>d</i> must be {@code 0}.
+     * <p>The selected decimal <i>d</i> is then formatted as a string.
+     * If <i>d</i> &lt; 0, the first character of the string is the sign
+     * '{@code -}'. Let |<i>d</i>| = <i>m</i>&middot;10<sup><i>k</i></sup>,
+     * for the unique pair of integer <i>k</i> and real <i>m</i> meeting
+     * 1 &le; <i>m</i> &lt; 10. Also, let the decimal expansion of
<i>m</i> be
+     *
<i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub>&thinsp;<!--
+     * -->&hellip;&thinsp;<i>m</i><sub><i>i</i></sub>,
+     * with <i>i</i> &ge; 1 and <i>m</i><sub><i>i</i></sub> &ne; 0.
+     * <ul>
+     *     <li>Case -3 &le; k &lt; 0: |<i>d</i>| is formatted as
+     *     0&thinsp;.&thinsp;0&hellip;0<i>m</i><sub>1</sub>&hellip;<!--
+     *     --><i>m</i><sub><i>i</i></sub>,
+     *     where there are exactly -<i>k</i> leading zeroes before
+     *     <i>m</i><sub>1</sub>, including the zero to the left of the
+     *     decimal point; for example, {@code "0.01234"}.
+     *     <li>Case 0 &le; <i>k</i> &lt; 7:
+     *     <ul>
+     *         <li>Subcase <i>i</i> &lt; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>0&hellip;0&thinsp;.&thinsp;0,
+     *         where there are exactly <i>k</i> + 2 - <i>i</i> trailing
zeroes
+     *         after <i>m</i><sub><i>i</i></sub>, including the zero to the
+     *         right of the decimal point; for example, {@code "1200.0"}.
+     *         <li>Subcase <i>i</i> &ge; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>k</i>+1</sub>&thinsp;.&thinsp;<!--
+     *         --><i>m</i><sub><i>k</i>+2</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>; for example, {@code
"1234.32"}.
+     *     </ul>
+     *     <li>Case <i>k</i> &lt; -3 or <i>k</i> &ge; 7:
+     *     computerized scientific notation is used to format |<i>d</i>|,
+     *     by combining <i>m</i> and <i>k</i> separated by the exponent
+     *     indicator '{@code E}'. The exponent <i>k</i> is formatted as in
+     *     {@link Integer#toString(int)}.
+     *     <ul>
+     *         <li>Subcase <i>i</i> = 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;0E<i>k</i>;
+     *         for example, {@code "2.0E23"}.
+     *         <li>Subcase <i>i</i> &gt; 1: |<i>d</i>| is formatted as
+     *
<i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub><!--
+     *         -->&hellip;<i>m</i><sub><i>i</i></sub>E<i>k</i>;
+     *         for example, {@code "1.234E-32"}.
+     *     </ul>
+     *  </ul>
      *
-     * <p>To create localized string representations of a floating-point
-     * value, use subclasses of {@link java.text.NumberFormat}.
-     *
-     * @param   d   the {@code double} to be converted.
-     * @return a string representation of the argument.
+     * @param  v the {@code double} to be rendered.
+     * @return a string rendering of the argument.
      */
-    public static String toString(double d) {
-        return FloatingDecimal.toJavaFormatString(d);
+    public static String toString(double v) {
+        return DoubleToDecimal.toString(v);
     }

     /**
diff --git a/src/java.base/share/classes/java/lang/Float.java
b/src/java.base/share/classes/java/lang/Float.java
--- a/src/java.base/share/classes/java/lang/Float.java
+++ b/src/java.base/share/classes/java/lang/Float.java
@@ -25,6 +25,7 @@

 package java.lang;

+import jdk.internal.math.FloatToDecimal;
 import jdk.internal.math.FloatingDecimal;
 import jdk.internal.HotSpotIntrinsicCandidate;

@@ -136,73 +137,107 @@
     public static final Class<Float> TYPE = (Class<Float>)
Class.getPrimitiveClass("float");

     /**
-     * Returns a string representation of the {@code float}
-     * argument. All characters mentioned below are ASCII characters.
+     * Returns a string rendering of the {@code float} argument.
+     *
+     * <p>The characters of the result are all drawn from the ASCII set.
      * <ul>
-     * <li>If the argument is NaN, the result is the string
-     * "{@code NaN}".
-     * <li>Otherwise, the result is a string that represents the sign and
-     *     magnitude (absolute value) of the argument. If the sign is
-     *     negative, the first character of the result is
-     *     '{@code -}' ({@code '\u005Cu002D'}); if the sign is
-     *     positive, no sign character appears in the result. As for
-     *     the magnitude <i>m</i>:
+     *     <li> Any NaN, whether quiet or signaling, is rendered
symbolically
+     *     as {@code "NaN"}, regardless of the sign bit.
+     *     <li> The infinities +&infin; and -&infin; are rendered as
+     *     {@code "Infinity"} and {@code "-Infinity"}, respectively.
+     *     <li> The positive and negative zeroes are rendered as
+     *     {@code "0.0"} and {@code "-0.0"}, respectively.
+     *     <li> Otherwise {@code v} is finite and non-zero.
+     *     It is rendered in two stages:
+     *     <ul>
+     *         <li> <em>Selection of a decimal</em>: A well-specified
non-zero
+     *         decimal <i>d</i> of finite length is selected to represent
+     *         {@code v}.
+     *         <li> <em>Formatting as a string</em>: The decimal
<i>d</i> is
+     *         formatted as a string, either in plain or in computerized
+     *         scientific notation, depending on its value.
+     *     </ul>
+     * </ul>
+     *
+     * <p>A number <i>d</i> is a decimal of finite length if and only
if it has
+     * the form <i>d</i> = <i>c</i>&middot;10<sup><i>q</i></sup> for some
+     * integers <i>c</i> and <i>q</i>. It has a length <i>n</i> if
+     * 10<sup><i>n</i>-1</sup> &le; |<i>c</i>| &lt; 10<sup><i>n</i></sup>.
+     * <p>The selected decimal <i>d</i> has all the following properties:
+     * <ul>
+     *     <li> It rounds to {@code v} according to the usual
round-to-closest
+     *     rule of IEEE 754 floating-point arithmetic.
+     *     <li> It has a shortest length <i>n</i> &ge; 2.
+     *     <li> It is the decimal closest to {@code v} among those
meeting the
+     *     previous properties.
+     * </ul>
+     * More formally, let <i>d'</i> =
<i>c'</i>&middot;10<sup><i>q'</i></sup>
+     * &ne; <i>d</i> be another decimal that also rounds to {@code v}
according
+     * to IEEE 754 and with a length <i>n'</i>. Then:
      * <ul>
-     * <li>If <i>m</i> is infinity, it is represented by the characters
-     *     {@code "Infinity"}; thus, positive infinity produces
-     *     the result {@code "Infinity"} and negative infinity
-     *     produces the result {@code "-Infinity"}.
-     * <li>If <i>m</i> is zero, it is represented by the characters
-     *     {@code "0.0"}; thus, negative zero produces the result
-     *     {@code "-0.0"} and positive zero produces the result
-     *     {@code "0.0"}.
-     * <li> If <i>m</i> is greater than or equal to 10<sup>-3</sup> but
-     *      less than 10<sup>7</sup>, then it is represented as the
-     *      integer part of <i>m</i>, in decimal form with no leading
-     *      zeroes, followed by '{@code .}'
-     *      ({@code '\u005Cu002E'}), followed by one or more
-     *      decimal digits representing the fractional part of
-     *      <i>m</i>.
-     * <li> If <i>m</i> is less than 10<sup>-3</sup> or greater than or
-     *      equal to 10<sup>7</sup>, then it is represented in
-     *      so-called "computerized scientific notation." Let <i>n</i>
-     *      be the unique integer such that 10<sup><i>n</i> </sup>&le;
-     *      <i>m</i> {@literal <} 10<sup><i>n</i>+1</sup>; then let
<i>a</i>
-     *      be the mathematically exact quotient of <i>m</i> and
-     *      10<sup><i>n</i></sup> so that 1 &le; <i>a</i> {@literal <} 10.
-     *      The magnitude is then represented as the integer part of
-     *      <i>a</i>, as a single decimal digit, followed by
-     *      '{@code .}' ({@code '\u005Cu002E'}), followed by
-     *      decimal digits representing the fractional part of
-     *      <i>a</i>, followed by the letter '{@code E}'
-     *      ({@code '\u005Cu0045'}), followed by a representation
-     *      of <i>n</i> as a decimal integer, as produced by the
-     *      method {@link java.lang.Integer#toString(int)}.
+     *     <li> <i>n'</i> = 1 (<i>d'</i> is too short) or
+     *     <li> <i>n'</i> &gt; <i>n</i> (<i>d'</i> is too long) or
+     *     <li> <i>n'</i> = <i>n</i> and
+     *     <ul>
+     *         <li> |<i>d</i> - {@code v}| &lt; |<i>d'</i> - {@code v}|
+     *         (<i>d'</i> is farther)
+     *         <li> |<i>d</i> - {@code v}| = |<i>d'</i> - {@code v}| and
+     *         <i>c</i> is even while <i>c'</i> is odd (tie-breaking
rule when
+     *         <i>d</i> and <i>d'</i> are equally close to {@code v})
+     *     </ul>
+     * </ul>
      *
-     * </ul>
-     * </ul>
-     * How many digits must be printed for the fractional part of
-     * <i>m</i> or <i>a</i>? There must be at least one digit
-     * to represent the fractional part, and beyond that as many, but
-     * only as many, more digits as are needed to uniquely distinguish
-     * the argument value from adjacent values of type
-     * {@code float}. That is, suppose that <i>x</i> is the
-     * exact mathematical value represented by the decimal
-     * representation produced by this method for a finite nonzero
-     * argument <i>f</i>. Then <i>f</i> must be the {@code float}
-     * value nearest to <i>x</i>; or, if two {@code float} values are
-     * equally close to <i>x</i>, then <i>f</i> must be one of
-     * them and the least significant bit of the significand of
-     * <i>f</i> must be {@code 0}.
+     * <p>The selected decimal <i>d</i> is then formatted as a string.
+     * If <i>d</i> &lt; 0, the first character of the string is the sign
+     * '{@code -}'. Let |<i>d</i>| = <i>m</i>&middot;10<sup><i>k</i></sup>,
+     * for the unique pair of integer <i>k</i> and real <i>m</i> meeting
+     * 1 &le; <i>m</i> &lt; 10. Also, let the decimal expansion of
<i>m</i> be
+     *
<i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub>&thinsp;<!--
+     * -->&hellip;&thinsp;<i>m</i><sub><i>i</i></sub>,
+     * with <i>i</i> &ge; 1 and <i>m</i><sub><i>i</i></sub> &ne; 0.
+     * <ul>
+     *     <li>Case -3 &le; k &lt; 0: |<i>d</i>| is formatted as
+     *     0&thinsp;.&thinsp;0&hellip;0<i>m</i><sub>1</sub>&hellip;<!--
+     *     --><i>m</i><sub><i>i</i></sub>,
+     *     where there are exactly -<i>k</i> leading zeroes before
+     *     <i>m</i><sub>1</sub>, including the zero to the left of the
+     *     decimal point; for example, {@code "0.01234"}.
+     *     <li>Case 0 &le; <i>k</i> &lt; 7:
+     *     <ul>
+     *         <li>Subcase <i>i</i> &lt; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>0&hellip;0&thinsp;.&thinsp;0,
+     *         where there are exactly <i>k</i> + 2 - <i>i</i> trailing
zeroes
+     *         after <i>m</i><sub><i>i</i></sub>, including the zero to the
+     *         right of the decimal point; for example, {@code "1200.0"}.
+     *         <li>Subcase <i>i</i> &ge; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>k</i>+1</sub>&thinsp;.&thinsp;<!--
+     *         --><i>m</i><sub><i>k</i>+2</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>; for example, {@code
"1234.32"}.
+     *     </ul>
+     *     <li>Case <i>k</i> &lt; -3 or <i>k</i> &ge; 7:
+     *     computerized scientific notation is used to format |<i>d</i>|,
+     *     by combining <i>m</i> and <i>k</i> separated by the exponent
+     *     indicator '{@code E}'. The exponent <i>k</i> is formatted as in
+     *     {@link Integer#toString(int)}.
+     *     <ul>
+     *         <li>Subcase <i>i</i> = 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;0E<i>k</i>;
+     *         for example, {@code "2.0E23"}.
+     *         <li>Subcase <i>i</i> &gt; 1: |<i>d</i>| is formatted as
+     *
<i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub><!--
+     *         -->&hellip;<i>m</i><sub><i>i</i></sub>E<i>k</i>;
+     *         for example, {@code "1.234E-32"}.
+     *     </ul>
+     *  </ul>
      *
-     * <p>To create localized string representations of a floating-point
-     * value, use subclasses of {@link java.text.NumberFormat}.
-     *
-     * @param   f   the float to be converted.
-     * @return a string representation of the argument.
+     * @param  v the {@code float} to be rendered.
+     * @return a string rendering of the argument.
      */
-    public static String toString(float f) {
-        return FloatingDecimal.toJavaFormatString(f);
+    public static String toString(float v) {
+        return FloatToDecimal.toString(v);
     }

     /**
diff --git
a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
@@ -0,0 +1,409 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+import static java.lang.Double.*;
+import static java.lang.Long.numberOfLeadingZeros;
+import static java.lang.Math.multiplyHigh;
+import static jdk.internal.math.MathUtils.*;
+
+/**
+ * This class exposes a method to render a {@code double} as a string.
+
+ * @author Raffaello Giulietti
+ */
+final public class DoubleToDecimal {
+
+    // Precision of normal values in bits.
+    private static final int P = 53;
+
+    // Length in bits of the exponent field.
+    private static final int W = (Double.SIZE - 1) - (P - 1);
+
+    // Minimum value of the exponent.
+    private static final int Q_MIN = (-1 << W - 1) - P + 3;
+
+    // Minimum value of the coefficient of a normal value.
+    private static final long C_MIN = 1L << P - 1;
+
+    // Mask to extract the IEEE 754-2008 biased exponent.
+    private static final int BQ_MASK = (1 << W) - 1;
+
+    // Mask to extract the IEEE 754-2008 fraction bits.
+    private static final long T_MASK = (1L << P - 1) - 1;
+
+    // H = min {n integer | 10^(n-1) > 2^P}
+    private static final int H = 17;
+
+    // used in the left-to-right extraction of the digits
+    private static final int LTR = 28;
+    private static final int MASK_LTR = (1 << LTR) - 1;
+
+    private static final long MASK_63 = (1L << Long.SIZE - 1) - 1;
+
+    // for thread-safety, each thread gets its own instance of this class
+    private static final ThreadLocal<DoubleToDecimal> threadLocal =
+            ThreadLocal.withInitial(DoubleToDecimal::new);
+
+    /*
+    Room for the longer of the forms
+        -ddddd.dddddddddddd         H + 2 characters
+        -0.00ddddddddddddddddd      H + 5 characters
+        -d.ddddddddddddddddE-eee    H + 7 characters
+    where there are H digits d
+     */
+    private final char[] buf = new char[H + 7];
+
+    // index of rightmost valid character
+    private int index;
+
+    private DoubleToDecimal() {
+    }
+
+    /*
+    See Double::toString for javadoc.
+     */
+    public static String toString(double v) {
+        return threadLocalInstance().toDecimal(v);
+    }
+
+    private static DoubleToDecimal threadLocalInstance() {
+        return threadLocal.get();
+    }
+
+    private String toDecimal(double v) {
+        long bits = doubleToRawLongBits(v);
+        int bq = (int) (bits >>> P - 1) & BQ_MASK;
+        if (bq < BQ_MASK) {
+            index = -1;
+            if (bits < 0) {
+                append('-');
+            }
+            if (bq > 0) {
+                return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK);
+            }
+            if (bits == 0x0000_0000_0000_0000L) {
+                return "0.0";
+            }
+            if (bits == 0x8000_0000_0000_0000L) {
+                return "-0.0";
+            }
+            return toDecimal(Q_MIN, bits & T_MASK);
+        }
+        if (v != v) {
+            return "NaN";
+        }
+        if (v == POSITIVE_INFINITY) {
+            return "Infinity";
+        }
+        return "-Infinity";
+    }
+
+    // Let v = c * 2^q be the absolute value of the original double.
Renders v.
+    private String toDecimal(int q, long c) {
+        /*
+        out = 0, if the boundaries of the rounding interval are included
+        out = 1, if they are excluded
+        d = 1 for even, d = 2 for uneven spacing around v.
+        v = cb * 2^qb
+        predecessor(v) = cbl * 2^qb
+        successor(v) = cbr * 2^qb
+         */
+        int out = (int) c & 0x1;
+
+        long cb;
+        long cbr;
+        long cbl;
+        int k;
+        int ord2alpha;
+        if (c != C_MIN | q == Q_MIN) {
+            cb = c << 1;
+            cbr = cb + 1;
+            k = flog10pow2(q);
+            ord2alpha = q + flog2pow10(-k) + 1;
+        } else {
+            cb = c << 2;
+            cbr = cb + 2;
+            k = flog10threeQuartersPow2(q);
+            ord2alpha = q + flog2pow10(-k);
+        }
+        cbl = cb - 1;
+        long mask = (1L << 63 - ord2alpha) - 1;
+        long threshold = 1L << 62 - ord2alpha;
+
+        // pow5 = pow51*2^63 + pow50
+        long pow51 = ceilPow5dHigh(-k);
+        long pow50 = ceilPow5dLow(-k);
+
+        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
+        long x0 = pow50 * cb;
+        long x1 = multiplyHigh(pow50, cb);
+        long y0 = pow51 * cb;
+        long y1 = multiplyHigh(pow51, cb);
+        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        long p0 = x0 & MASK_63;
+        long p1 = z & MASK_63;
+        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vn |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbl
+        x0 = pow50 * cbl;
+        x1 = multiplyHigh(pow50, cbl);
+        y0 = pow51 * cbl;
+        y1 = multiplyHigh(pow51, cbl);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnl |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbr
+        x0 = pow50 * cbr;
+        x1 = multiplyHigh(pow50, cbr);
+        y0 = pow51 * cbr;
+        y1 = multiplyHigh(pow51, cbr);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnr |= 1;
+        }
+
+        long s = vn >> 2;
+        if (s >= 100) {
+            long s10 = s - s % 10;
+            long t10 = s10 + 10;
+            boolean uin10 = vnl + out <= s10 << 1;
+            boolean win10 = (t10 << 1) + out <= vnr;
+            if (uin10 | win10) {
+                if (!win10) {
+                    return toChars(s10, k);
+                }
+                if (!uin10) {
+                    return toChars(t10, k);
+                }
+            }
+        } else if (s < 10) {
+            /*
+            Special cases that need to be made artificially longer to meet
+            the specification
+             */
+            switch ((int) s) {
+                case 4: return toChars(49, -325); // 4.9 * 10^-324
+                case 9: return toChars(99, -325); // 9.9 * 10^-324
+            }
+        }
+        long t = s + 1;
+        boolean uin = vnl + out <= s << 1;
+        boolean win = (t << 1) + out <= vnr;
+        if (!win) {
+            return toChars(s, k);
+        }
+        if (!uin) {
+            return toChars(t, k);
+        }
+        long cmp = vn - (s + t << 1);
+        if (cmp < 0) {
+            return toChars(s, k);
+        }
+        if (cmp > 0) {
+            return toChars(t, k);
+        }
+        if ((s & 1) == 0) {
+            return toChars(s, k);
+        }
+        return toChars(t, k);
+    }
+
+    /*
+    The method formats the number f * 10^e
+
+    Division is avoided altogether by replacing it with multiplications
+    and shifts. This has a noticeable impact on performance.
+    For more in-depth readings, see for example
+    * Moeller & Granlund, "Improved division by invariant integers"
+    * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned
+        Division by Constants"
+
+    Also, once the quotient is known, the remainder is computed indirectly.
+     */
+    private String toChars(long f, int e) {
+        // Normalize f to lie in the f-independent interval [10^(H-1),
10^H)
+        int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f));
+        if (f >= pow10[len10]) {
+            len10 += 1;
+        }
+        // 10^(len10-1) <= f < 10^len10
+        f *= pow10[H - len10];
+        e += len10;
+
+        /*
+        Split the H = 17 digits of f into:
+            h = the most significant digit of f
+            m = the next 8 most significant digits of f
+            l = the last 8, least significant digits of f
+
+        Pictorially, the selected decimal to format as String is
+            0.hmmmmmmmmllllllll * 10^e
+        Depending on the value of e, plain or computerized scientific
notation
+        is used.
+         */
+        long hm = multiplyHigh(f, 48_357_032_784_585_167L) >>> 18;
+        int l = (int) (f - 100_000_000L * hm);
+        int h = (int) (hm * 1_441_151_881L >>> 57);
+        int m = (int) (hm - 100_000_000 * h);
+
+        /*
+        The left-to-right digits generation in toChars_* is inspired by
+        * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal
Conversion"
+         */
+        if (0 < e && e <= 7) {
+            return toChars_1(h, m, l, e);
+        }
+        if (-3 < e && e <= 0) {
+            return toChars_2(h, m, l, e);
+        }
+        return toChars_3(h, m, l, e);
+    }
+
+    // 0 < e <= 7: plain format without leading zeroes.
+    private String toChars_1(int h, int m, int l, int e) {
+        appendDigit(h);
+        // y = (m + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh(
+                (long) (m + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        int t;
+        int i = 1;
+        for (; i < e; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        append('.');
+        for (; i <= 8; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        lowDigits(l);
+        return charsToString();
+    }
+
+    // -3 < e <= 0: plain format with leading zeroes.
+    private String toChars_2(int h, int m, int l, int e) {
+        appendDigit(0);
+        append('.');
+        for (; e < 0; ++e) {
+          appendDigit(0);
+        }
+        appendDigit(h);
+        append8Digits(m);
+        lowDigits(l);
+        return charsToString();
+    }
+
+    // -3 >= e | e > 7: computerized scientific notation
+    private String toChars_3(int h, int m, int l, int e) {
+        appendDigit(h);
+        append('.');
+        append8Digits(m);
+        lowDigits(l);
+        exponent(e - 1);
+        return charsToString();
+    }
+
+    private void lowDigits(int l) {
+        if (l != 0) {
+            append8Digits(l);
+        }
+        removeTrailingZeroes();
+    }
+
+    private void append8Digits(int v) {
+        // y = (v + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh((long) (v + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        for (int i = 0; i < 8; ++i) {
+            int t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+    }
+
+    private void removeTrailingZeroes() {
+        while (buf[index] == '0') {
+            --index;
+        }
+        if (buf[index] == '.') {
+            ++index;
+        }
+    }
+
+    private void exponent(int e) {
+        append('E');
+        if (e < 0) {
+            append('-');
+            e = -e;
+        }
+        if (e < 10) {
+            appendDigit(e);
+            return;
+        }
+        if (e < 100) {
+            // d = e / 10
+            int d = e * 205 >>> 11;
+            appendDigit(d);
+            appendDigit(e - 10 * d);
+            return;
+        }
+        // d = e / 100
+        int d = e * 1_311 >>> 17;
+        appendDigit(d);
+        e -= 100 * d;
+        // d = e / 10
+        d = e * 205 >>> 11;
+        appendDigit(d);
+        appendDigit(e - 10 * d);
+    }
+
+    private void append(int c) {
+        buf[++index] = (char) c;
+    }
+
+    private void appendDigit(int d) {
+        buf[++index] = (char) ('0' + d);
+    }
+
+    private String charsToString() {
+        return new String(buf, 0, index + 1);
+    }
+
+}
diff --git
a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
@@ -0,0 +1,393 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+import static java.lang.Float.*;
+import static java.lang.Long.numberOfLeadingZeros;
+import static java.lang.Math.multiplyHigh;
+import static jdk.internal.math.MathUtils.*;
+
+/**
+ * This class exposes a method to render a {@code float} as a string.
+
+ * @author Raffaello Giulietti
+ */
+final public class FloatToDecimal {
+
+    // Precision of normal values in bits.
+    private static final int P = 24;
+
+    // Length in bits of the exponent field.
+    private static final int W = (Float.SIZE - 1) - (P - 1);
+
+    // Minimum value of the exponent.
+    private static final int Q_MIN = (-1 << W - 1) - P + 3;
+
+    // Minimum value of the coefficient of a normal value.
+    private static final int C_MIN = 1 << P - 1;
+
+    // Mask to extract the IEEE 754-2008 biased exponent.
+    private static final int BQ_MASK = (1 << W) - 1;
+
+    // Mask to extract the IEEE 754-2008 fraction bits.
+    private static final int T_MASK = (1 << P - 1) - 1;
+
+    // H = min {n integer | 10^(n-1) > 2^P}
+    private static final int H = 9;
+
+    // used in the left-to-right extraction of the digits
+    private static final int LTR = 28;
+    private static final int MASK_LTR = (1 << LTR) - 1;
+
+    private static final long MASK_63 = (1L << Long.SIZE - 1) - 1;
+
+    // for thread-safety, each thread gets its own instance of this class
+    private static final ThreadLocal<FloatToDecimal> threadLocal =
+            ThreadLocal.withInitial(FloatToDecimal::new);
+
+    /*
+    Room for the longer of the forms
+        -ddddd.dddd         H + 2 characters
+        -0.00ddddddddd      H + 5 characters
+        -d.ddddddddE-ee     H + 6 characters
+    where there are H digits d
+     */
+    private final char[] buf = new char[H + 6];
+
+    // index of rightmost valid character
+    private int index;
+
+    private FloatToDecimal() {
+    }
+
+    /*
+    See Float::toString for javadoc.
+     */
+    public static String toString(float v) {
+        return threadLocalInstance().toDecimal(v);
+    }
+
+    private static FloatToDecimal threadLocalInstance() {
+        return threadLocal.get();
+    }
+
+    private String toDecimal(float v) {
+        int bits = floatToRawIntBits(v);
+        int bq = (bits >>> P - 1) & BQ_MASK;
+        if (bq < BQ_MASK) {
+            index = -1;
+            if (bits < 0) {
+                append('-');
+            }
+            if (bq > 0) {
+                return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK);
+            }
+            if (bits == 0x0000_0000) {
+                return "0.0";
+            }
+            if (bits == 0x8000_0000) {
+                return "-0.0";
+            }
+            return toDecimal(Q_MIN, bits & T_MASK);
+        }
+        if (v != v) {
+            return "NaN";
+        }
+        if (v == POSITIVE_INFINITY) {
+            return "Infinity";
+        }
+        return "-Infinity";
+    }
+
+    // Let v = c * 2^q be the absolute value of the original float.
Renders v.
+    private String toDecimal(int q, int c) {
+        /*
+        out = 0, if the boundaries of the rounding interval are included
+        out = 1, if they are excluded
+        d = 1 for even, d = 2 for uneven spacing around v.
+        v = cb * 2^qb
+        predecessor(v) = cbl * 2^qb
+        successor(v) = cbr * 2^qb
+         */
+        int out = c & 0x1;
+
+        long cb;
+        long cbr;
+        long cbl;
+        int k;
+        int ord2alpha;
+        if (c != C_MIN | q == Q_MIN) {
+            cb = c << 1;
+            cbr = cb + 1;
+            k = flog10pow2(q);
+            ord2alpha = q + flog2pow10(-k) + 1;
+        } else {
+            cb = c << 2;
+            cbr = cb + 2;
+            k = flog10threeQuartersPow2(q);
+            ord2alpha = q + flog2pow10(-k);
+        }
+        cbl = cb - 1;
+        long mask = (1L << 63 - ord2alpha) - 1;
+        long threshold = 1L << 62 - ord2alpha;
+
+        // pow5 = pow51*2^63 + pow50
+        long pow51 = ceilPow5dHigh(-k);
+        long pow50 = ceilPow5dLow(-k);
+
+        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
+        long x0 = pow50 * cb;
+        long x1 = multiplyHigh(pow50, cb);
+        long y0 = pow51 * cb;
+        long y1 = multiplyHigh(pow51, cb);
+        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        long p0 = x0 & MASK_63;
+        long p1 = z & MASK_63;
+        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vn |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbl
+        x0 = pow50 * cbl;
+        x1 = multiplyHigh(pow50, cbl);
+        y0 = pow51 * cbl;
+        y1 = multiplyHigh(pow51, cbl);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnl |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbr
+        x0 = pow50 * cbr;
+        x1 = multiplyHigh(pow50, cbr);
+        y0 = pow51 * cbr;
+        y1 = multiplyHigh(pow51, cbr);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnr |= 1;
+        }
+
+        long s = vn >> 2;
+        if (s >= 100) {
+            long s10 = s - s % 10;
+            long t10 = s10 + 10;
+            boolean uin10 = vnl + out <= s10 << 1;
+            boolean win10 = (t10 << 1) + out <= vnr;
+            if (uin10 | win10) {
+                if (!win10) {
+                    return toChars(s10, k);
+                }
+                if (!uin10) {
+                    return toChars(t10, k);
+                }
+            }
+        } else if (s < 10) {
+            /*
+            Special cases that need to be made artificially longer to meet
+            the specification
+             */
+            switch ((int) s) {
+                case 1: return toChars(14, -46); // 1.4 * 10^-45
+                case 2: return toChars(28, -46); // 2.8 * 10^-45
+                case 4: return toChars(42, -46); // 4.2 * 10^-45
+                case 5: return toChars(56, -46); // 5.6 * 10^-45
+                case 7: return toChars(70, -46); // 7.0 * 10^-45
+                case 8: return toChars(84, -46); // 8.4 * 10^-45
+                case 9: return toChars(98, -46); // 9.8 * 10^-45
+            }
+        }
+        long t = s + 1;
+        boolean uin = vnl + out <= s << 1;
+        boolean win = (t << 1) + out <= vnr;
+        if (!win) {
+            return toChars(s, k);
+        }
+        if (!uin) {
+            return toChars(t, k);
+        }
+        long cmp = vn - (s + t << 1);
+        if (cmp < 0) {
+            return toChars(s, k);
+        }
+        if (cmp > 0) {
+            return toChars(t, k);
+        }
+        if ((s & 1) == 0) {
+            return toChars(s, k);
+        }
+        return toChars(t, k);
+    }
+
+    /*
+    The method formats the number f * 10^e
+
+    Division is avoided altogether by replacing it with multiplications
+    and shifts. This has a noticeable impact on performance.
+    For more in-depth readings, see for example
+    * Moeller & Granlund, "Improved division by invariant integers"
+    * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned
+        Division by Constants"
+
+    Also, once the quotient is known, the remainder is computed indirectly.
+     */
+    private String toChars(long f, int e) {
+        // Normalize f to lie in the f-independent interval [10^(H-1),
10^H)
+        int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f));
+        if (f >= pow10[len10]) {
+            len10 += 1;
+        }
+        // 10^(len10-1) <= f < 10^len10
+        f *= pow10[H - len10];
+        e += len10;
+
+        /*
+        Split the H = 9 digits of f into:
+            h = the most significant digit of f
+            l = the last 8, least significant digits of f
+
+        Pictorially, the selected decimal to format as String is
+            0.hllllllll * 10^e
+        Depending on the value of e, plain or computerized scientific
notation
+        is used.
+         */
+        int h = (int) (f * 1_441_151_881L >>> 57);
+        int l = (int) (f - 100_000_000 * h);
+
+        /*
+        The left-to-right digits generation in toChars_* is inspired by
+        * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal
Conversion"
+         */
+        if (0 < e && e <= 7) {
+            return toChars_1(h, l, e);
+        }
+        if (-3 < e && e <= 0) {
+            return toChars_2(h, l, e);
+        }
+        return toChars_3(h, l, e);
+    }
+
+    // 0 < e <= 7: plain format without leading zeroes.
+    private String toChars_1(int h, int l, int e) {
+        appendDigit(h);
+        // y = (l + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh(
+                (long) (l + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        int t;
+        int i = 1;
+        for (; i < e; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        append('.');
+        for (; i <= 8; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        removeTrailingZeroes();
+        return charsToString();
+    }
+
+    // -3 < e <= 0: plain format with leading zeroes.
+    private String toChars_2(int h, int l, int e) {
+        appendDigit(0);
+        append('.');
+        for (; e < 0; ++e) {
+          appendDigit(0);
+        }
+        appendDigit(h);
+        append8Digits(l);
+        removeTrailingZeroes();
+        return charsToString();
+    }
+
+    // -3 >= e | e > 7: computerized scientific notation
+    private String toChars_3(int h, int l, int e) {
+        appendDigit(h);
+        append('.');
+        append8Digits(l);
+        removeTrailingZeroes();
+        exponent(e - 1);
+        return charsToString();
+    }
+
+    private void append8Digits(int v) {
+        // y = (v + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh((long) (v + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        for (int i = 0; i < 8; ++i) {
+            int t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+    }
+
+    private void removeTrailingZeroes() {
+        while (buf[index] == '0') {
+            --index;
+        }
+        if (buf[index] == '.') {
+            ++index;
+        }
+    }
+
+    private void exponent(int e) {
+        append('E');
+        if (e < 0) {
+            append('-');
+            e = -e;
+        }
+        if (e < 10) {
+            appendDigit(e);
+            return;
+        }
+        // d = e / 10
+        int d = e * 205 >>> 11;
+        appendDigit(d);
+        appendDigit(e - 10 * d);
+    }
+
+    private void append(int c) {
+        buf[++index] = (char) c;
+    }
+
+    private void appendDigit(int d) {
+        buf[++index] = (char) ('0' + d);
+    }
+
+    private String charsToString() {
+        return new String(buf, 0, index + 1);
+    }
+
+}
diff --git
a/src/java.base/share/classes/jdk/internal/math/MathUtils.java
b/src/java.base/share/classes/jdk/internal/math/MathUtils.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java
@@ -0,0 +1,775 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+/**
+ * @author Raffaello Giulietti
+ */
+final class MathUtils {
+
+    // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10)
+    private static final int Q_10 = 41;
+    private static final long C_10 = 661_971_961_083L;
+    private static final long A_10 = -274_743_187_321L;
+
+    // C_2 = floor(log2(10) * 2^Q_2)
+    private static final int Q_2 = 38;
+    private static final long C_2 = 913_124_641_741L;
+
+    // The minimum exponent for ceilPow5dHigh(int)
+    private static final int MIN_EXP = -292;
+
+    private MathUtils() {
+    }
+
+    // pow10[i] = 10^i, 0 <= i <= H
+    static final long[] pow10 = {
+        1L,
+        10L,
+        100L,
+        1_000L,
+        10_000L,
+        100_000L,
+        1_000_000L,
+        10_000_000L,
+        100_000_000L,
+        1_000_000_000L,
+        10_000_000_000L,
+        100_000_000_000L,
+        1_000_000_000_000L,
+        10_000_000_000_000L,
+        100_000_000_000_000L,
+        1_000_000_000_000_000L,
+        10_000_000_000_000_000L,
+        100_000_000_000_000_000L,
+    };
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 10<sup><i>k</i></sup> &le; 2<sup>{@code e}</sup>
+     * &lt; 10<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when |{@code e}| &le; 5_456_721.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 2, which should meet
+     *          |{@code e}| &le; 5_456_721 for safe results.
+     * @return &lfloor;log<sub>10</sub>2<sup>{@code e}</sup>&rfloor;.
+     */
+    static int flog10pow2(int e) {
+        return (int) (e * C_10 >> Q_10);
+    }
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 10<sup><i>k</i></sup> &le; 3/4 &middot; 2<sup>{@code e}</sup>
+     * &lt; 10<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when
+     * -2_956_395 &le; |{@code e}| &le; 2_500_325.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 2, which should meet
+     *          -2_956_395 &le; |{@code e}| &le; 2_500_325 for safe
results.
+     * @return &lfloor;log<sub>10</sub>(3/4 &middot;
+     * 2<sup>{@code e}</sup>)&rfloor;.
+     */
+    static int flog10threeQuartersPow2(int e) {
+        return (int) ((e * C_10 + A_10) >> Q_10);
+    }
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 2<sup><i>k</i></sup> &le; 10<sup>{@code e}</sup>
+     * &lt; 2<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when |{@code e}| &le; 1_838_394.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 10, which should meet
+     *          |{@code e}| &le; 1_838_394 for safe results.
+     * @return &lfloor;log<sub>2</sub>10<sup>{@code e}</sup>&rfloor;.
+     */
+    static int flog2pow10(int e) {
+        return (int) (e * C_2 >> Q_2);
+    }
+
+    /**
+     * Let 5<sup>{@code e}</sup> = <i>d</i> &middot; 2<sup><i>r</i></sup>,
+     * for the unique pair of integer <i>r</i> and real <i>d</i> meeting
+     * 2<sup>125</sup> &le; d &lt; 2<sup>126</sup>.
+     * Further, let <i>c</i> = &lceil;<i>d</i>&rceil;.
+     * Split <i>c</i> into the higher 63 bits <i>c</i><sub>1</sub> and
+     * the lower 63 bits <i>c</i><sub>0</sub>. Thus,
+     * <i>c</i><sub>1</sub> =
+     * &lfloor;<i>c</i> &middot; 2<sup>-63</sup>&rfloor;
+     * and
+     * <i>c</i><sub>0</sub> =
+     * <i>c</i> - <i>c</i><sub>1</sub> &middot; 2<sup>63</sup>.
+     * <p>
+     * This method returns <i>c</i><sub>1</sub> while
+     * {@link #ceilPow5dLow(int)} returns <i>c</i><sub>0</sub>.
+     * <p>
+     * If needed, the exponent <i>r</i> can be computed as
+     * <i>r</i> = {@code flog2pow10(e) - e - 125}
+     * (see {@link #flog2pow10(int)}).
+     *
+     * @param e The exponent of 5,
+     *          which must meet -292 &le; {@code e} &le; 324.
+     * @return <i>c</i><sub>1</sub> as described above.
+     */
+    static long ceilPow5dHigh(int e) {
+        return ceilPow5d[e - MIN_EXP << 1];
+    }
+
+    /**
+     * Returns <i>c</i><sub>0</sub> as described in {@link
#ceilPow5dHigh(int)}.
+     *
+     * @param e The exponent of 5,
+     *          which must meet -292 &le; {@code e} &le; 324.
+     * @return <i>c</i><sub>0</sub> as described in {@link
#ceilPow5dHigh(int)}.
+     */
+    static long ceilPow5dLow(int e) {
+        return ceilPow5d[e - MIN_EXP << 1 | 1];
+    }
+
+    private static final long[] ceilPow5d = {
+        /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL,
+        /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL,
+        /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L,
+        /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L,
+        /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL,
+        /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L,
+        /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L,
+        /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL,
+        /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L,
+        /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL,
+        /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL,
+        /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L,
+        /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL,
+        /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L,
+        /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L,
+        /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL,
+        /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L,
+        /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L,
+        /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L,
+        /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL,
+        /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L,
+        /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L,
+        /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L,
+        /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL,
+        /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L,
+        /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L,
+        /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL,
+        /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L,
+        /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L,
+        /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L,
+        /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L,
+        /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL,
+        /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL,
+        /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L,
+        /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L,
+        /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL,
+        /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L,
+        /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L,
+        /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L,
+        /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L,
+        /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L,
+        /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L,
+        /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL,
+        /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L,
+        /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L,
+        /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L,
+        /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L,
+        /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L,
+        /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L,
+        /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L,
+        /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L,
+        /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L,
+        /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL,
+        /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L,
+        /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L,
+        /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL,
+        /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L,
+        /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL,
+        /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L,
+        /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L,
+        /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL,
+        /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L,
+        /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L,
+        /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L,
+        /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL,
+        /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L,
+        /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L,
+        /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L,
+        /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL,
+        /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L,
+        /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L,
+        /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L,
+        /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L,
+        /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL,
+        /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L,
+        /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L,
+        /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL,
+        /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L,
+        /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L,
+        /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L,
+        /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L,
+        /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L,
+        /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L,
+        /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL,
+        /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL,
+        /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L,
+        /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L,
+        /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL,
+        /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL,
+        /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L,
+        /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L,
+        /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL,
+        /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L,
+        /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L,
+        /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L,
+        /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L,
+        /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL,
+        /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L,
+        /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L,
+        /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L,
+        /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L,
+        /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L,
+        /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L,
+        /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L,
+        /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L,
+        /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L,
+        /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L,
+        /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L,
+        /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L,
+        /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L,
+        /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L,
+        /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L,
+        /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL,
+        /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L,
+        /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL,
+        /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL,
+        /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L,
+        /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L,
+        /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L,
+        /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L,
+        /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L,
+        /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L,
+        /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L,
+        /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L,
+        /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L,
+        /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL,
+        /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL,
+        /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L,
+        /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL,
+        /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L,
+        /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L,
+        /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL,
+        /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L,
+        /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL,
+        /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL,
+        /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL,
+        /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL,
+        /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L,
+        /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL,
+        /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L,
+        /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL,
+        /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L,
+        /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L,
+        /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL,
+        /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL,
+        /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL,
+        /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L,
+        /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL,
+        /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L,
+        /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL,
+        /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L,
+        /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L,
+        /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL,
+        /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L,
+        /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L,
+        /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL,
+        /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L,
+        /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L,
+        /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L,
+        /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL,
+        /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL,
+        /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL,
+        /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L,
+        /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL,
+        /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L,
+        /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL,
+        /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L,
+        /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL,
+        /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL,
+        /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L,
+        /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L,
+        /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL,
+        /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL,
+        /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL,
+        /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L,
+        /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL,
+        /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL,
+        /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L,
+        /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L,
+        /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L,
+        /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L,
+        /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L,
+        /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L,
+        /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L,
+        /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL,
+        /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L,
+        /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL,
+        /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L,
+        /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L,
+        /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L,
+        /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL,
+        /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL,
+        /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL,
+        /*  -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L,
+        /*  -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL,
+        /*  -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL,
+        /*  -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L,
+        /*  -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L,
+        /*  -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L,
+        /*  -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L,
+        /*  -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L,
+        /*  -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL,
+        /*  -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L,
+        /*  -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL,
+        /*  -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL,
+        /*  -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL,
+        /*  -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L,
+        /*  -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL,
+        /*  -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL,
+        /*  -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL,
+        /*  -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL,
+        /*  -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L,
+        /*  -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L,
+        /*  -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L,
+        /*  -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL,
+        /*  -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L,
+        /*  -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL,
+        /*  -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L,
+        /*  -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L,
+        /*  -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL,
+        /*  -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL,
+        /*  -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L,
+        /*  -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L,
+        /*  -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL,
+        /*  -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L,
+        /*  -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L,
+        /*  -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L,
+        /*  -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL,
+        /*  -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL,
+        /*  -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL,
+        /*  -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL,
+        /*  -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L,
+        /*  -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L,
+        /*  -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L,
+        /*  -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L,
+        /*  -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL,
+        /*  -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L,
+        /*  -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL,
+        /*  -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L,
+        /*  -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL,
+        /*  -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL,
+        /*  -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL,
+        /*  -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L,
+        /*  -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL,
+        /*  -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L,
+        /*  -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL,
+        /*  -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL,
+        /*  -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L,
+        /*  -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL,
+        /*  -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L,
+        /*  -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L,
+        /*  -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L,
+        /*  -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L,
+        /*  -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L,
+        /*  -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L,
+        /*  -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L,
+        /*  -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL,
+        /*  -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL,
+        /*  -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L,
+        /*  -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L,
+        /*  -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL,
+        /*  -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L,
+        /*  -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L,
+        /*  -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL,
+        /*  -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L,
+        /*  -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L,
+        /*  -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L,
+        /*  -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L,
+        /*  -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L,
+        /*  -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L,
+        /*  -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL,
+        /*  -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L,
+        /*  -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L,
+        /*  -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL,
+        /*  -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L,
+        /*  -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L,
+        /*  -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL,
+        /*  -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L,
+        /*  -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L,
+        /*  -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL,
+        /*  -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L,
+        /*  -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L,
+        /*  -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L,
+        /*   -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL,
+        /*   -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L,
+        /*   -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L,
+        /*   -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L,
+        /*   -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L,
+        /*   -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL,
+        /*   -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL,
+        /*   -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L,
+        /*   -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L,
+        /*    0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0000L,
+        /*   15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0000L,
+        /*   16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0000L,
+        /*   17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0000L,
+        /*   18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0000L,
+        /*   19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0000L,
+        /*   20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0000L,
+        /*   21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0000L,
+        /*   22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0000L,
+        /*   23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0000L,
+        /*   24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0000L,
+        /*   25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0000L,
+        /*   26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0000L,
+        /*   27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0000L,
+        /*   28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0000L,
+        /*   29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0000L,
+        /*   30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0000L,
+        /*   31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0000L,
+        /*   32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0000L,
+        /*   33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0000L,
+        /*   34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0000L,
+        /*   35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0000L,
+        /*   36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0000L,
+        /*   37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0000L,
+        /*   38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0000L,
+        /*   39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0000L,
+        /*   40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0000L,
+        /*   41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0000L,
+        /*   42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0000L,
+        /*   43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0000L,
+        /*   44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0000L,
+        /*   45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0000L,
+        /*   46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0000L,
+        /*   47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0000L,
+        /*   48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4000L,
+        /*   49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5000L,
+        /*   50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B200L,
+        /*   51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E80L,
+        /*   52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B620L,
+        /*   53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D4L,
+        /*   54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F649L,
+        /*   55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL,
+        /*   56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL,
+        /*   57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L,
+        /*   58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L,
+        /*   59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL,
+        /*   60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L,
+        /*   61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL,
+        /*   62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL,
+        /*   63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL,
+        /*   64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL,
+        /*   65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL,
+        /*   66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL,
+        /*   67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L,
+        /*   68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L,
+        /*   69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL,
+        /*   70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L,
+        /*   71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L,
+        /*   72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L,
+        /*   73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L,
+        /*   74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L,
+        /*   75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L,
+        /*   76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L,
+        /*   77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L,
+        /*   78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL,
+        /*   79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L,
+        /*   80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L,
+        /*   81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L,
+        /*   82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L,
+        /*   83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L,
+        /*   84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL,
+        /*   85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL,
+        /*   86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L,
+        /*   87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL,
+        /*   88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L,
+        /*   89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL,
+        /*   90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L,
+        /*   91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL,
+        /*   92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L,
+        /*   93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL,
+        /*   94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L,
+        /*   95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L,
+        /*   96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L,
+        /*   97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L,
+        /*   98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L,
+        /*   99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L,
+        /*  100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L,
+        /*  101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL,
+        /*  102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L,
+        /*  103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL,
+        /*  104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L,
+        /*  105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL,
+        /*  106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL,
+        /*  107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L,
+        /*  108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L,
+        /*  109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L,
+        /*  110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L,
+        /*  111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L,
+        /*  112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL,
+        /*  113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L,
+        /*  114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L,
+        /*  115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L,
+        /*  116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L,
+        /*  117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L,
+        /*  118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL,
+        /*  119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL,
+        /*  120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL,
+        /*  121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL,
+        /*  122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L,
+        /*  123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL,
+        /*  124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L,
+        /*  125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L,
+        /*  126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L,
+        /*  127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L,
+        /*  128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL,
+        /*  129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L,
+        /*  130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL,
+        /*  131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL,
+        /*  132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL,
+        /*  133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL,
+        /*  134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L,
+        /*  135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L,
+        /*  136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL,
+        /*  137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL,
+        /*  138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L,
+        /*  139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL,
+        /*  140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL,
+        /*  141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L,
+        /*  142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL,
+        /*  143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL,
+        /*  144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL,
+        /*  145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L,
+        /*  146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L,
+        /*  147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL,
+        /*  148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L,
+        /*  149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL,
+        /*  150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL,
+        /*  151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL,
+        /*  152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL,
+        /*  153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L,
+        /*  154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL,
+        /*  155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL,
+        /*  156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L,
+        /*  157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL,
+        /*  158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L,
+        /*  159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL,
+        /*  160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L,
+        /*  161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L,
+        /*  162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L,
+        /*  163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L,
+        /*  164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL,
+        /*  165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L,
+        /*  166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL,
+        /*  167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L,
+        /*  168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L,
+        /*  169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L,
+        /*  170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL,
+        /*  171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L,
+        /*  172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L,
+        /*  173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL,
+        /*  174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL,
+        /*  175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL,
+        /*  176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L,
+        /*  177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L,
+        /*  178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL,
+        /*  179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L,
+        /*  180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L,
+        /*  181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L,
+        /*  182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L,
+        /*  183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L,
+        /*  184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL,
+        /*  185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL,
+        /*  186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL,
+        /*  187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL,
+        /*  188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL,
+        /*  189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL,
+        /*  190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L,
+        /*  191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL,
+        /*  192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L,
+        /*  193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L,
+        /*  194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL,
+        /*  195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L,
+        /*  196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L,
+        /*  197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L,
+        /*  198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL,
+        /*  199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L,
+        /*  200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L,
+        /*  201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L,
+        /*  202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL,
+        /*  203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L,
+        /*  204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL,
+        /*  205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL,
+        /*  206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L,
+        /*  207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL,
+        /*  208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L,
+        /*  209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L,
+        /*  210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL,
+        /*  211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L,
+        /*  212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L,
+        /*  213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L,
+        /*  214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL,
+        /*  215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL,
+        /*  216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L,
+        /*  217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL,
+        /*  218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L,
+        /*  219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L,
+        /*  220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L,
+        /*  221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L,
+        /*  222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L,
+        /*  223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L,
+        /*  224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL,
+        /*  225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L,
+        /*  226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L,
+        /*  227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL,
+        /*  228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L,
+        /*  229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L,
+        /*  230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL,
+        /*  231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L,
+        /*  232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L,
+        /*  233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L,
+        /*  234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L,
+        /*  235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL,
+        /*  236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL,
+        /*  237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L,
+        /*  238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L,
+        /*  239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L,
+        /*  240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL,
+        /*  241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL,
+        /*  242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL,
+        /*  243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L,
+        /*  244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL,
+        /*  245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL,
+        /*  246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL,
+        /*  247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L,
+        /*  248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L,
+        /*  249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L,
+        /*  250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L,
+        /*  251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L,
+        /*  252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L,
+        /*  253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL,
+        /*  254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L,
+        /*  255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L,
+        /*  256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL,
+        /*  257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL,
+        /*  258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L,
+        /*  259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL,
+        /*  260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L,
+        /*  261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL,
+        /*  262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L,
+        /*  263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL,
+        /*  264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L,
+        /*  265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL,
+        /*  266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L,
+        /*  267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L,
+        /*  268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL,
+        /*  269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL,
+        /*  270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL,
+        /*  271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L,
+        /*  272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L,
+        /*  273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L,
+        /*  274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L,
+        /*  275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L,
+        /*  276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L,
+        /*  277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L,
+        /*  278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL,
+        /*  279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL,
+        /*  280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL,
+        /*  281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L,
+        /*  282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL,
+        /*  283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L,
+        /*  284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L,
+        /*  285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L,
+        /*  286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L,
+        /*  287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL,
+        /*  288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L,
+        /*  289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL,
+        /*  290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L,
+        /*  291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL,
+        /*  292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL,
+        /*  293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L,
+        /*  294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL,
+        /*  295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L,
+        /*  296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L,
+        /*  297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L,
+        /*  298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL,
+        /*  299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L,
+        /*  300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L,
+        /*  301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL,
+        /*  302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L,
+        /*  303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL,
+        /*  304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL,
+        /*  305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L,
+        /*  306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L,
+        /*  307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL,
+        /*  308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L,
+        /*  309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L,
+        /*  310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L,
+        /*  311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L,
+        /*  312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L,
+        /*  313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L,
+        /*  314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL,
+        /*  315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L,
+        /*  316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL,
+        /*  317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL,
+        /*  318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L,
+        /*  319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L,
+        /*  320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L,
+        /*  321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L,
+        /*  322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L,
+        /*  323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL,
+        /*  324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L,
+    };
+
+}
diff --git a/test/jdk/java/lang/Floating/DoubleToDecString.java
b/test/jdk/java/lang/Floating/DoubleToDecString.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/DoubleToDecString.java
@@ -0,0 +1,312 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.util.Random;
+
+import static java.lang.Math.*;
+import static java.lang.Double.*;
+
+/*
+ * @test
+ * @bug 8202555
+
+ * @author Raffaello Giulietti
+ */
+public class DoubleToDecString {
+
+    private static final boolean FAILURE_THROWS_EXCEPTION = true;
+
+    private static void assertTrue(boolean ok, double v, String s) {
+        if (ok) {
+            return;
+        }
+        String message = "Double::toString applied to " +
+                "Double.longBitsToDouble(" +
+                "0x" + Long.toHexString(doubleToRawLongBits(v)) + "L" +
+                ")" +
+                " returns " +
+                "\"" + s + "\"" +
+                ", which is not correct according to the specification.";
+        if (FAILURE_THROWS_EXCEPTION) {
+            throw new RuntimeException(message);
+        }
+        System.err.println(message);
+    }
+
+    private static void toDec(double v) {
+        String s = Double.toString(v);
+        assertTrue(new DoubleToStringChecker(v, s).isOK(), v, s);
+    }
+
+    private static void testExtremeValues() {
+        toDec(NEGATIVE_INFINITY);
+        toDec(-MAX_VALUE);
+        toDec(-MIN_NORMAL);
+        toDec(-MIN_VALUE);
+        toDec(-0.0);
+        toDec(0.0);
+        toDec(MIN_VALUE);
+        toDec(MIN_NORMAL);
+        toDec(MAX_VALUE);
+        toDec(POSITIVE_INFINITY);
+        toDec(NaN);
+        /*
+        Quiet NaNs have the most significant bit of the mantissa as 1,
+        while signaling NaNs have it as 0.
+        Exercise 4 combinations of quiet/signaling NaNs and
+        "positive/negative" NaNs
+         */
+        toDec(longBitsToDouble(0x7FF8_0000_0000_0001L));
+        toDec(longBitsToDouble(0x7FF0_0000_0000_0001L));
+        toDec(longBitsToDouble(0xFFF8_0000_0000_0001L));
+        toDec(longBitsToDouble(0xFFF0_0000_0000_0001L));
+    }
+
+    /*
+    A few "powers of 10" are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf10() {
+        for (int e = -323; e <= 309; ++e) {
+            toDec(parseDouble("1e" + e));
+        }
+    }
+
+    /*
+    Many powers of 2 are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf2() {
+        for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) {
+            toDec(v);
+        }
+    }
+
+    /*
+    There are tons of doubles that are rendered incorrectly by the JDK.
+    While the renderings correctly round back to the original value,
+    they are longer than needed or are not the closest decimal to the
double.
+    Here are just a very few examples.
+     */
+    private static final String[] Anomalies = {
+            // JDK renders these, and others, with 18 digits!
+            "2.82879384806159E17", "1.387364135037754E18",
+            "1.45800632428665E17",
+
+            // JDK renders these longer than needed.
+            "1.6E-322", "6.3E-322",
+            "7.3879E20", "2.0E23", "7.0E22", "9.2E22",
+            "9.5E21", "3.1E22", "5.63E21", "8.41E21",
+
+            // JDK does not render these, and many others, as the closest.
+            "9.9E-324", "9.9E-323",
+            "1.9400994884341945E25", "3.6131332396758635E25",
+            "2.5138990223946153E25",
+    };
+
+    private static void testSomeAnomalies() {
+        for (String dec : Anomalies) {
+            toDec(parseDouble(dec));
+        }
+    }
+
+    /*
+    Values are from
+    Paxson V, "A Program for Testing IEEE Decimal?Binary Conversion"
+     */
+    private static final double[] PaxsonSignificands = {
+            8_511_030_020_275_656L,
+            5_201_988_407_066_741L,
+            6_406_892_948_269_899L,
+            8_431_154_198_732_492L,
+            6_475_049_196_144_587L,
+            8_274_307_542_972_842L,
+            5_381_065_484_265_332L,
+            6_761_728_585_499_734L,
+            7_976_538_478_610_756L,
+            5_982_403_858_958_067L,
+            5_536_995_190_630_837L,
+            7_225_450_889_282_194L,
+            7_225_450_889_282_194L,
+            8_703_372_741_147_379L,
+            8_944_262_675_275_217L,
+            7_459_803_696_087_692L,
+            6_080_469_016_670_379L,
+            8_385_515_147_034_757L,
+            7_514_216_811_389_786L,
+            8_397_297_803_260_511L,
+            6_733_459_239_310_543L,
+            8_091_450_587_292_794L,
+
+            6_567_258_882_077_402L,
+            6_712_731_423_444_934L,
+            6_712_731_423_444_934L,
+            5_298_405_411_573_037L,
+            5_137_311_167_659_507L,
+            6_722_280_709_661_868L,
+            5_344_436_398_034_927L,
+            8_369_123_604_277_281L,
+            8_995_822_108_487_663L,
+            8_942_832_835_564_782L,
+            8_942_832_835_564_782L,
+            8_942_832_835_564_782L,
+            6_965_949_469_487_146L,
+            6_965_949_469_487_146L,
+            6_965_949_469_487_146L,
+            7_487_252_720_986_826L,
+            5_592_117_679_628_511L,
+            8_887_055_249_355_788L,
+            6_994_187_472_632_449L,
+            8_797_576_579_012_143L,
+            7_363_326_733_505_337L,
+            8_549_497_411_294_502L,
+    };
+
+    private static final int[] PaxsonExponents = {
+            -342,
+            -824,
+             237,
+              72,
+              99,
+             726,
+            -456,
+             -57,
+             376,
+             377,
+              93,
+             710,
+             709,
+             117,
+              -1,
+            -707,
+            -381,
+             721,
+            -828,
+            -345,
+             202,
+            -473,
+
+             952,
+             535,
+             534,
+            -957,
+            -144,
+             363,
+            -169,
+            -853,
+            -780,
+            -383,
+            -384,
+            -385,
+            -249,
+            -250,
+            -251,
+             548,
+             164,
+             665,
+             690,
+             588,
+             272,
+            -448,
+    };
+
+    private static void testPaxson() {
+        for (int i = 0; i < PaxsonSignificands.length; ++i) {
+            toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i]));
+        }
+    }
+
+    /*
+    Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0.
+    These are all exact doubles.
+     */
+    private static void testLongs() {
+        for (int i = 10_000; i < 100_000; ++i) {
+            toDec(i * 1e15);
+        }
+    }
+
+    /*
+    Tests all integers up to 100_000.
+    These are all exact doubles.
+     */
+    private static void testInts() {
+        for (int i = 0; i <= 1_000_000; ++i) {
+            toDec(i);
+        }
+    }
+
+    /*
+    Random doubles over the whole range
+     */
+    private static void testRandom() {
+        Random r = new Random();
+        for (int i = 0; i < 1_000_000; ++i) {
+            toDec(longBitsToDouble(r.nextLong()));
+        }
+    }
+
+    /*
+    Random doubles over the integer range [0, 10^15).
+    These integers are all exact doubles.
+     */
+    private static void testRandomUnit() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec(r.nextLong() % 1_000_000_000_000_000L);
+        }
+    }
+
+    /*
+    Random doubles over the range [0, 10^15) as "multiples" of 1e-3
+     */
+    private static void testRandomMilli() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3);
+        }
+    }
+
+    /*
+    Random doubles over the range [0, 10^15) as "multiples" of 1e-6
+     */
+    private static void testRandomMicro() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6);
+        }
+    }
+
+    public static void main(String[] args) {
+        testExtremeValues();
+        testSomeAnomalies();
+        testPowersOf2();
+        testPowersOf10();
+        testPaxson();
+        testInts();
+        testLongs();
+        testRandom();
+        testRandomUnit();
+        testRandomMilli();
+        testRandomMicro();
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/DoubleToStringChecker.java
b/test/jdk/java/lang/Floating/DoubleToStringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/DoubleToStringChecker.java
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+class DoubleToStringChecker extends StringChecker {
+
+    private double v;
+
+    DoubleToStringChecker(double v, String s) {
+        super(s);
+        this.v = v;
+    }
+
+    @Override
+    BigDecimal toBigDecimal() {
+        return new BigDecimal(v);
+    }
+
+    @Override
+    boolean recovers(BigDecimal b) {
+        return b.doubleValue() == v;
+    }
+
+    @Override
+    boolean recovers(String s) {
+        return Double.parseDouble(s) == v;
+    }
+
+    @Override
+    int maxExp() {
+        return 309;
+    }
+
+    @Override
+    int minExp() {
+        return -323;
+    }
+
+    @Override
+    int maxLen10() {
+        return 17;
+    }
+
+    @Override
+    boolean isZero() {
+        return v == 0;
+    }
+
+    @Override
+    boolean isInfinity() {
+        return v == Double.POSITIVE_INFINITY;
+    }
+
+    @Override
+    void invert() {
+        v = -v;
+    }
+
+    @Override
+    boolean isNegative() {
+        return Double.doubleToRawLongBits(v) < 0;
+    }
+
+    @Override
+    boolean isNaN() {
+        return v != v;
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/FloatToDecString.java
b/test/jdk/java/lang/Floating/FloatToDecString.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/FloatToDecString.java
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.util.Random;
+
+import static java.lang.Float.*;
+
+/*
+ * @test
+
+ * @author Raffaello Giulietti
+ */
+public class FloatToDecString {
+
+    private static final boolean FAILURE_THROWS_EXCEPTION = true;
+
+    private static void assertTrue(boolean ok, float v, String s) {
+        if (ok) {
+            return;
+        }
+        String message = "Float::toString applied to " +
+                "Float.intBitsToFloat(" +
+                "0x" + Integer.toHexString(floatToRawIntBits(v)) +
+                ")" +
+                " returns " +
+                "\"" + s + "\"" +
+                ", which is not correct according to the specification.";
+        if (FAILURE_THROWS_EXCEPTION) {
+            throw new RuntimeException(message);
+        }
+        System.err.println(message);
+    }
+
+    private static void toDec(float v) {
+        String s = Float.toString(v);
+        assertTrue(new FloatToStringChecker(v, s).isOK(), v, s);
+    }
+
+    /*
+    MIN_NORMAL is incorrectly rendered by the JDK.
+     */
+    private static void testExtremeValues() {
+        toDec(NEGATIVE_INFINITY);
+        toDec(-MAX_VALUE);
+        toDec(-MIN_NORMAL);
+        toDec(-MIN_VALUE);
+        toDec(-0.0f);
+        toDec(0.0f);
+        toDec(MIN_VALUE);
+        toDec(MIN_NORMAL);
+        toDec(MAX_VALUE);
+        toDec(POSITIVE_INFINITY);
+        toDec(NaN);
+        /*
+        Quiet NaNs have the most significant bit of the mantissa as 1,
+        while signaling NaNs have it as 0.
+        Exercise 4 combinations of quiet/signaling NaNs and
+        "positive/negative" NaNs.
+         */
+        toDec(intBitsToFloat(0x7FC0_0001));
+        toDec(intBitsToFloat(0x7F80_0001));
+        toDec(intBitsToFloat(0xFFC0_0001));
+        toDec(intBitsToFloat(0xFF80_0001));
+    }
+
+    /*
+    Many "powers of 10" are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf10() {
+        for (int e = -44; e <= 39; ++e) {
+            toDec(parseFloat("1e" + e));
+        }
+    }
+
+    /*
+    Many powers of 2 are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf2() {
+        for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) {
+            toDec(v);
+        }
+    }
+
+    /*
+    Tests all integers up to 1_000_000.
+    These are all exact floats.
+     */
+    private static void testInts() {
+        for (int i = 0; i <= 1_000_000; ++i) {
+            toDec(i);
+        }
+    }
+
+    /*
+    Random floats over the whole range.
+     */
+    private static void testRandom() {
+        Random r = new Random();
+        for (int i = 0; i < 1_000_000; ++i) {
+            toDec(intBitsToFloat(r.nextInt()));
+        }
+    }
+
+    /*
+    All, really all, possible floats. Takes between 90 and 120 minutes.
+     */
+    private static void testAll() {
+        int bits = Integer.MIN_VALUE;
+        for (; bits < Integer.MAX_VALUE; ++bits) {
+            toDec(Float.intBitsToFloat(bits));
+        }
+        toDec(Float.intBitsToFloat(bits));
+    }
+
+    public static void main(String[] args) {
+//        testAll();
+        testExtremeValues();
+        testPowersOf2();
+        testPowersOf10();
+        testInts();
+        testRandom();
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/FloatToStringChecker.java
b/test/jdk/java/lang/Floating/FloatToStringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/FloatToStringChecker.java
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+class FloatToStringChecker extends StringChecker {
+
+    private float v;
+
+    FloatToStringChecker(float v, String s) {
+        super(s);
+        this.v = v;
+    }
+
+    @Override
+    BigDecimal toBigDecimal() {
+        return new BigDecimal(v);
+    }
+
+    @Override
+    boolean recovers(BigDecimal b) {
+        return b.floatValue() == v;
+    }
+
+    @Override
+    boolean recovers(String s) {
+        return Float.parseFloat(s) == v;
+    }
+
+    @Override
+    int maxExp() {
+        return 39;
+    }
+
+    @Override
+    int minExp() {
+        return -44;
+    }
+
+    @Override
+    int maxLen10() {
+        return 9;
+    }
+
+    @Override
+    boolean isZero() {
+        return v == 0;
+    }
+
+    @Override
+    boolean isInfinity() {
+        return v == Float.POSITIVE_INFINITY;
+    }
+
+    @Override
+    void invert() {
+        v = -v;
+    }
+
+    @Override
+    boolean isNegative() {
+        return Float.floatToRawIntBits(v) < 0;
+    }
+
+    @Override
+    boolean isNaN() {
+        return v != v;
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/StringChecker.java
b/test/jdk/java/lang/Floating/StringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/StringChecker.java
@@ -0,0 +1,348 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.io.IOException;
+import java.io.StringReader;
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+abstract class StringChecker {
+
+    private String s;
+    private long c;
+    private int q;
+    private int len10;
+
+    StringChecker(String s) {
+        this.s = s;
+    }
+
+    /*
+    Returns whether s syntactically meets the expected output of
+    Double::toString. It is restricted to finite positive outputs.
+    It is an unusually long method but rather straightforward, too.
+    Many conditionals could be merged, but KISS here.
+     */
+    private boolean parse() {
+        try {
+            // first determine interesting boundaries in the string
+            StringReader r = new StringReader(s);
+            int ch = r.read();
+
+            int i = 0;
+            while (ch == '0') {
+                ++i;
+                ch = r.read();
+            }
+            // i is just after zeroes starting the integer
+
+            int p = i;
+            while ('0' <= ch && ch <= '9') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++p;
+                ch = r.read();
+            }
+            // p is just after digits ending the integer
+
+            int fz = p;
+            if (ch == '.') {
+                ++fz;
+                ch = r.read();
+            }
+            // fz is just after a decimal '.'
+
+            int f = fz;
+            while (ch == '0') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++f;
+                ch = r.read();
+            }
+            // f is just after zeroes starting the fraction
+
+            if (c == 0) {
+                len10 = 0;
+            }
+            int x = f;
+            while ('0' <= ch && ch <= '9') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++x;
+                ch = r.read();
+            }
+            // x is just after digits ending the fraction
+
+            int g = x;
+            if (ch == 'E') {
+                ++g;
+                ch = r.read();
+            }
+            // g is just after an exponent indicator 'E'
+
+            int ez = g;
+            if (ch == '-') {
+                ++ez;
+                ch = r.read();
+            }
+            // ez is just after a '-' sign in the exponent
+
+            int e = ez;
+            while (ch == '0') {
+                ++e;
+                ch = r.read();
+            }
+            // e is just after zeroes starting the exponent
+
+            int z = e;
+            while ('0' <= ch && ch <= '9') {
+                q = 10 * q + (ch - '0');
+                if (q < 0) {
+                    return false;
+                }
+                ++z;
+                ch = r.read();
+            }
+            // z is just after digits ending the exponent
+
+            // No other char after the number
+            if (z != s.length()) {
+                return false;
+            }
+
+            // The integer must be present
+            if (p == 0) {
+                return false;
+            }
+
+            // The decimal '.' must be present
+            if (fz == p) {
+                return false;
+            }
+
+            // The fraction must be present
+            if (x == fz) {
+                return false;
+            }
+
+            // The fraction is not 0 or it consists of exactly one 0
+            if (f == x && f - fz > 1) {
+                return false;
+            }
+
+            // Plain notation, no exponent
+            if (x == z) {
+                // At most one 0 starting the integer
+                if (i > 1) {
+                    return false;
+                }
+
+                // If the integer is 0, at most 2 zeroes start the fraction
+                if (i == 1 && f - fz > 2) {
+                    return false;
+                }
+
+                // The integer cannot have more than 7 digits
+                if (p > 7) {
+                    return false;
+                }
+
+                q = fz - x;
+
+                // OK for plain notation
+                return true;
+            }
+
+            // Computerized scientific notation
+
+            // The integer has exactly one nonzero digit
+            if (i != 0 || p != 1) {
+                return false;
+            }
+
+            //
+            // There must be an exponent indicator
+            if (x == g) {
+                return false;
+            }
+
+            // There must be an exponent
+            if (ez == z) {
+                return false;
+            }
+
+            // The exponent must not start with zeroes
+            if (ez != e) {
+                return false;
+            }
+
+            if (g != ez) {
+                q = -q;
+            }
+
+            // The exponent must not lie in [-3, 7)
+            if (-3 <= q && q < 7) {
+                return false;
+            }
+
+            q += fz - x;
+
+            // OK for computerized scientific notation
+            return true;
+        } catch (IOException ex) {
+            // An IOException on a StringReader??? Please...
+            return false;
+        }
+    }
+
+    boolean isOK() {
+        if (isNaN()) {
+            return s.equals("NaN");
+        }
+        if (isNegative()) {
+            if (s.isEmpty() || s.charAt(0) != '-') {
+                return false;
+            }
+            invert();
+            s = s.substring(1);
+        }
+        if (isInfinity()) {
+            return s.equals("Infinity");
+        }
+        if (isZero()) {
+            return s.equals("0.0");
+        }
+        if (!parse()) {
+            return false;
+        }
+        if (len10 < 2) {
+            c *= 10;
+            q -= 1;
+            len10 += 1;
+        }
+        if (2 > len10 || len10 > maxLen10()) {
+            return false;
+        }
+
+        // The exponent is bounded
+        if (minExp() > q + len10 || q + len10 > maxExp()) {
+            return false;
+        }
+
+        // s must recover v
+        try {
+            if (!recovers(s)) {
+                return false;
+            }
+        } catch (NumberFormatException e) {
+            return false;
+        }
+
+        // Get rid of trailing zeroes, still ensuring at least 2 digits
+        while (len10 > 2 && c % 10 == 0) {
+            c /= 10;
+            q += 1;
+            len10 -= 1;
+        }
+
+        if (len10 > 2) {
+            // Try with a shorter number less than v...
+            if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) {
+                return false;
+            }
+
+            // ... and with a shorter number greater than v
+            if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) {
+                return false;
+            }
+        }
+
+        // Try with the decimal predecessor...
+        BigDecimal dp = c == 10 ?
+                BigDecimal.valueOf(99, -q + 1) :
+                BigDecimal.valueOf(c - 1, -q);
+        if (recovers(dp)) {
+            BigDecimal bv = toBigDecimal();
+            BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q));
+            if (deltav.signum() >= 0) {
+                return true;
+            }
+            BigDecimal delta = dp.subtract(bv);
+            if (delta.signum() >= 0) {
+                return false;
+            }
+            int cmp = deltav.compareTo(delta);
+            return cmp > 0 || cmp == 0 && (c & 0x1) == 0;
+        }
+
+        // ... and with the decimal successor
+        BigDecimal ds = BigDecimal.valueOf(c + 1, -q);
+        if (recovers(ds)) {
+            BigDecimal bv = toBigDecimal();
+            BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q));
+            if (deltav.signum() <= 0) {
+                return true;
+            }
+            BigDecimal delta = ds.subtract(bv);
+            if (delta.signum() <= 0) {
+                return false;
+            }
+            int cmp = deltav.compareTo(delta);
+            return cmp < 0 || cmp == 0 && (c & 0x1) == 0;
+        }
+
+        return true;
+    }
+
+    abstract BigDecimal toBigDecimal();
+
+    abstract boolean recovers(BigDecimal b);
+
+    abstract boolean recovers(String s);
+
+    abstract int maxExp();
+
+    abstract int minExp();
+
+    abstract int maxLen10();
+
+    abstract boolean isZero();
+
+    abstract boolean isInfinity();
+
+    abstract void invert();
+
+    abstract boolean isNegative();
+
+    abstract boolean isNaN();
+
+}





-------------- next part --------------
# HG changeset patch
# User lello
# Date 1537948169 -7200
#      Wed Sep 26 09:49:29 2018 +0200
# Node ID 6bd9d2c45440c578b93d2f07e5eaea73928be4d5
# Parent  5f931e3e7a63b550d832d2624db32033b875c720
Patches to fix JDK-4511638

diff --git a/src/java.base/share/classes/java/lang/Double.java b/src/java.base/share/classes/java/lang/Double.java
--- a/src/java.base/share/classes/java/lang/Double.java
+++ b/src/java.base/share/classes/java/lang/Double.java
@@ -25,6 +25,7 @@
 
 package java.lang;
 
+import jdk.internal.math.DoubleToDecimal;
 import jdk.internal.math.FloatingDecimal;
 import jdk.internal.math.DoubleConsts;
 import jdk.internal.HotSpotIntrinsicCandidate;
@@ -139,69 +140,108 @@
     public static final Class<Double>   TYPE = (Class<Double>) Class.getPrimitiveClass("double");
 
     /**
-     * Returns a string representation of the {@code double}
-     * argument. All characters mentioned below are ASCII characters.
-     * <ul>
-     * <li>If the argument is NaN, the result is the string
-     *     "{@code NaN}".
-     * <li>Otherwise, the result is a string that represents the sign and
-     * magnitude (absolute value) of the argument. If the sign is negative,
-     * the first character of the result is '{@code -}'
-     * ({@code '\u005Cu002D'}); if the sign is positive, no sign character
-     * appears in the result. As for the magnitude <i>m</i>:
+     * Returns a string rendering of the {@code double} argument.
+     *
+     * <p>The characters of the result are all drawn from the ASCII set.
      * <ul>
-     * <li>If <i>m</i> is infinity, it is represented by the characters
-     * {@code "Infinity"}; thus, positive infinity produces the result
-     * {@code "Infinity"} and negative infinity produces the result
-     * {@code "-Infinity"}.
+     *     <li> Any NaN, whether quiet or signaling, is rendered symbolically
+     *     as {@code "NaN"}, regardless of the sign bit.
+     *     <li> The infinities +&infin; and -&infin; are rendered as
+     *     {@code "Infinity"} and {@code "-Infinity"}, respectively.
+     *     <li> The positive and negative zeroes are rendered as
+     *     {@code "0.0"} and {@code "-0.0"}, respectively.
+     *     <li> Otherwise {@code v} is finite and non-zero.
+     *     It is rendered in two stages:
+     *     <ul>
+     *         <li> <em>Selection of a decimal</em>: A well-specified non-zero
+     *         decimal <i>d</i> is selected to represent {@code v}.
+     *         <li> <em>Formatting as a string</em>: The decimal <i>d</i> is
+     *         formatted as a string, either in plain or in computerized
+     *         scientific notation, depending on its value.
+     *     </ul>
+     * </ul>
      *
-     * <li>If <i>m</i> is zero, it is represented by the characters
-     * {@code "0.0"}; thus, negative zero produces the result
-     * {@code "-0.0"} and positive zero produces the result
-     * {@code "0.0"}.
-     *
-     * <li>If <i>m</i> is greater than or equal to 10<sup>-3</sup> but less
-     * than 10<sup>7</sup>, then it is represented as the integer part of
-     * <i>m</i>, in decimal form with no leading zeroes, followed by
-     * '{@code .}' ({@code '\u005Cu002E'}), followed by one or
-     * more decimal digits representing the fractional part of <i>m</i>.
+     * <p>The selected decimal <i>d</i> has a length <i>n</i> if it can be
+     * written as <i>d</i> = <i>c</i>&middot;10<sup><i>q</i></sup> for some
+     * integers <i>q</i> and <i>c</i> meeting 10<sup><i>n</i>-1</sup> &le;
+     * |<i>c</i>| &lt; 10<sup><i>n</i></sup>. It has all the following
+     * properties:
+     * <ul>
+     *     <li> It rounds to {@code v} according to the usual round-to-closest
+     *     rule of IEEE 754 floating-point arithmetic.
+     *     <li> Among the decimals above, it has a length of 2 or more.
+     *     <li> Among all such decimals, it is one of those with the shortest
+     *     length.
+     *     <li> Among the latter ones, it is the one closest to {@code v}. Or
+     *     if there are two that are equally close to {@code v}, it is the one
+     *     whose least significant digit is even.
+     * </ul>
+     * More formally, let <i>d'</i> = <i>c'</i>&middot;10<sup><i>q'</i></sup>
+     * &ne; <i>d</i> be any other decimal that rounds to {@code v} according to
+     * IEEE 754 and of a length <i>n'</i>. Then:
+     * <ul>
+     *     <li> either <i>n'</i> = 1, thus <i>d'</i> is too short;
+     *     <li> or <i>n'</i> &gt; <i>n</i>, thus <i>d'</i> is too long;
+     *     <li> or <i>n'</i> = <i>n</i> and
+     *     <ul>
+     *         <li> either |<i>d</i> - {@code v}| &lt; |<i>d'</i> - {@code v}|:
+     *         thus <i>d'</i> is farther from {@code v};
+     *         <li> or |<i>d</i> - {@code v}| = |<i>d'</i> - {@code v}| and
+     *         <i>c</i> is even while <i>c'</i> is odd
+     *     </ul>
+     * </ul>
      *
-     * <li>If <i>m</i> is less than 10<sup>-3</sup> or greater than or
-     * equal to 10<sup>7</sup>, then it is represented in so-called
-     * "computerized scientific notation." Let <i>n</i> be the unique
-     * integer such that 10<sup><i>n</i></sup> &le; <i>m</i> {@literal <}
-     * 10<sup><i>n</i>+1</sup>; then let <i>a</i> be the
-     * mathematically exact quotient of <i>m</i> and
-     * 10<sup><i>n</i></sup> so that 1 &le; <i>a</i> {@literal <} 10. The
-     * magnitude is then represented as the integer part of <i>a</i>,
-     * as a single decimal digit, followed by '{@code .}'
-     * ({@code '\u005Cu002E'}), followed by decimal digits
-     * representing the fractional part of <i>a</i>, followed by the
-     * letter '{@code E}' ({@code '\u005Cu0045'}), followed
-     * by a representation of <i>n</i> as a decimal integer, as
-     * produced by the method {@link Integer#toString(int)}.
-     * </ul>
-     * </ul>
-     * How many digits must be printed for the fractional part of
-     * <i>m</i> or <i>a</i>? There must be at least one digit to represent
-     * the fractional part, and beyond that as many, but only as many, more
-     * digits as are needed to uniquely distinguish the argument value from
-     * adjacent values of type {@code double}. That is, suppose that
-     * <i>x</i> is the exact mathematical value represented by the decimal
-     * representation produced by this method for a finite nonzero argument
-     * <i>d</i>. Then <i>d</i> must be the {@code double} value nearest
-     * to <i>x</i>; or if two {@code double} values are equally close
-     * to <i>x</i>, then <i>d</i> must be one of them and the least
-     * significant bit of the significand of <i>d</i> must be {@code 0}.
+     * <p>The selected decimal <i>d</i> is then formatted as a string.
+     * If <i>d</i> &lt; 0, the first character of the string is the sign
+     * '{@code -}'. Let |<i>d</i>| = <i>m</i>&middot;10<sup><i>k</i></sup>,
+     * for the unique pair of integer <i>k</i> and real <i>m</i> meeting
+     * 1 &le; <i>m</i> &lt; 10. Also, let the decimal expansion of <i>m</i> be
+     * <i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub>&thinsp;<!--
+     * -->&hellip;&thinsp;<i>m</i><sub><i>i</i></sub>,
+     * with <i>i</i> &ge; 1 and <i>m</i><sub><i>i</i></sub> &ne; 0.
+     * <ul>
+     *     <li>Case -3 &le; k &lt; 0: |<i>d</i>| is formatted as
+     *     0&thinsp;.&thinsp;0&hellip;0<i>m</i><sub>1</sub>&hellip;<!--
+     *     --><i>m</i><sub><i>i</i></sub>,
+     *     where there are exactly -<i>k</i> leading zeroes before
+     *     <i>m</i><sub>1</sub>, including the zero to the left of the
+     *     decimal point; for example, {@code "0.01234"}.
+     *     <li>Case 0 &le; <i>k</i> &lt; 7:
+     *     <ul>
+     *         <li>Subcase <i>i</i> &lt; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>0&hellip;0&thinsp;.&thinsp;0,
+     *         where there are exactly <i>k</i> + 2 - <i>i</i> trailing zeroes
+     *         after <i>m</i><sub><i>i</i></sub>, including the zero to the
+     *         right of the decimal point; for example, {@code "1200.0"}.
+     *         <li>Subcase <i>i</i> &ge; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>k</i>+1</sub>&thinsp;.&thinsp;<!--
+     *         --><i>m</i><sub><i>k</i>+2</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>; for example, {@code "1234.32"}.
+     *     </ul>
+     *     <li>Case <i>k</i> &lt; -3 or <i>k</i> &ge; 7:
+     *     computerized scientific notation is used to format |<i>d</i>|,
+     *     by combining <i>m</i> and <i>k</i> separated by the exponent
+     *     indicator '{@code E}'. The exponent <i>k</i> is formatted as in
+     *     {@link Integer#toString(int)}.
+     *     <ul>
+     *         <li>Subcase <i>i</i> = 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;0E<i>k</i>;
+     *         for example, {@code "2.0E23"}.
+     *         <li>Subcase <i>i</i> &gt; 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub><!--
+     *         -->&hellip;<i>m</i><sub><i>i</i></sub>E<i>k</i>;
+     *         for example, {@code "1.234E-32"}.
+     *     </ul>
+     *  </ul>
      *
-     * <p>To create localized string representations of a floating-point
-     * value, use subclasses of {@link java.text.NumberFormat}.
-     *
-     * @param   d   the {@code double} to be converted.
-     * @return a string representation of the argument.
+     * @param  v the {@code double} to be rendered.
+     * @return a string rendering of the argument.
      */
-    public static String toString(double d) {
-        return FloatingDecimal.toJavaFormatString(d);
+    public static String toString(double v) {
+        return DoubleToDecimal.toString(v);
     }
 
     /**
diff --git a/src/java.base/share/classes/java/lang/Float.java b/src/java.base/share/classes/java/lang/Float.java
--- a/src/java.base/share/classes/java/lang/Float.java
+++ b/src/java.base/share/classes/java/lang/Float.java
@@ -25,6 +25,7 @@
 
 package java.lang;
 
+import jdk.internal.math.FloatToDecimal;
 import jdk.internal.math.FloatingDecimal;
 import jdk.internal.HotSpotIntrinsicCandidate;
 
@@ -136,73 +137,107 @@
     public static final Class<Float> TYPE = (Class<Float>) Class.getPrimitiveClass("float");
 
     /**
-     * Returns a string representation of the {@code float}
-     * argument. All characters mentioned below are ASCII characters.
+     * Returns a string rendering of the {@code float} argument.
+     *
+     * <p>The characters of the result are all drawn from the ASCII set.
      * <ul>
-     * <li>If the argument is NaN, the result is the string
-     * "{@code NaN}".
-     * <li>Otherwise, the result is a string that represents the sign and
-     *     magnitude (absolute value) of the argument. If the sign is
-     *     negative, the first character of the result is
-     *     '{@code -}' ({@code '\u005Cu002D'}); if the sign is
-     *     positive, no sign character appears in the result. As for
-     *     the magnitude <i>m</i>:
+     *     <li> Any NaN, whether quiet or signaling, is rendered symbolically
+     *     as {@code "NaN"}, regardless of the sign bit.
+     *     <li> The infinities +&infin; and -&infin; are rendered as
+     *     {@code "Infinity"} and {@code "-Infinity"}, respectively.
+     *     <li> The positive and negative zeroes are rendered as
+     *     {@code "0.0"} and {@code "-0.0"}, respectively.
+     *     <li> Otherwise {@code v} is finite and non-zero.
+     *     It is rendered in two stages:
+     *     <ul>
+     *         <li> <em>Selection of a decimal</em>: A well-specified non-zero
+     *         decimal <i>d</i> of finite length is selected to represent
+     *         {@code v}.
+     *         <li> <em>Formatting as a string</em>: The decimal <i>d</i> is
+     *         formatted as a string, either in plain or in computerized
+     *         scientific notation, depending on its value.
+     *     </ul>
+     * </ul>
+     *
+     * <p>A number <i>d</i> is a decimal of finite length if and only if it has
+     * the form <i>d</i> = <i>c</i>&middot;10<sup><i>q</i></sup> for some
+     * integers <i>c</i> and <i>q</i>. It has a length <i>n</i> if
+     * 10<sup><i>n</i>-1</sup> &le; |<i>c</i>| &lt; 10<sup><i>n</i></sup>.
+     * <p>The selected decimal <i>d</i> has all the following properties:
+     * <ul>
+     *     <li> It rounds to {@code v} according to the usual round-to-closest
+     *     rule of IEEE 754 floating-point arithmetic.
+     *     <li> It has a shortest length <i>n</i> &ge; 2.
+     *     <li> It is the decimal closest to {@code v} among those meeting the
+     *     previous properties.
+     * </ul>
+     * More formally, let <i>d'</i> = <i>c'</i>&middot;10<sup><i>q'</i></sup>
+     * &ne; <i>d</i> be another decimal that also rounds to {@code v} according
+     * to IEEE 754 and with a length <i>n'</i>. Then:
      * <ul>
-     * <li>If <i>m</i> is infinity, it is represented by the characters
-     *     {@code "Infinity"}; thus, positive infinity produces
-     *     the result {@code "Infinity"} and negative infinity
-     *     produces the result {@code "-Infinity"}.
-     * <li>If <i>m</i> is zero, it is represented by the characters
-     *     {@code "0.0"}; thus, negative zero produces the result
-     *     {@code "-0.0"} and positive zero produces the result
-     *     {@code "0.0"}.
-     * <li> If <i>m</i> is greater than or equal to 10<sup>-3</sup> but
-     *      less than 10<sup>7</sup>, then it is represented as the
-     *      integer part of <i>m</i>, in decimal form with no leading
-     *      zeroes, followed by '{@code .}'
-     *      ({@code '\u005Cu002E'}), followed by one or more
-     *      decimal digits representing the fractional part of
-     *      <i>m</i>.
-     * <li> If <i>m</i> is less than 10<sup>-3</sup> or greater than or
-     *      equal to 10<sup>7</sup>, then it is represented in
-     *      so-called "computerized scientific notation." Let <i>n</i>
-     *      be the unique integer such that 10<sup><i>n</i> </sup>&le;
-     *      <i>m</i> {@literal <} 10<sup><i>n</i>+1</sup>; then let <i>a</i>
-     *      be the mathematically exact quotient of <i>m</i> and
-     *      10<sup><i>n</i></sup> so that 1 &le; <i>a</i> {@literal <} 10.
-     *      The magnitude is then represented as the integer part of
-     *      <i>a</i>, as a single decimal digit, followed by
-     *      '{@code .}' ({@code '\u005Cu002E'}), followed by
-     *      decimal digits representing the fractional part of
-     *      <i>a</i>, followed by the letter '{@code E}'
-     *      ({@code '\u005Cu0045'}), followed by a representation
-     *      of <i>n</i> as a decimal integer, as produced by the
-     *      method {@link java.lang.Integer#toString(int)}.
+     *     <li> <i>n'</i> = 1 (<i>d'</i> is too short) or
+     *     <li> <i>n'</i> &gt; <i>n</i> (<i>d'</i> is too long) or
+     *     <li> <i>n'</i> = <i>n</i> and
+     *     <ul>
+     *         <li> |<i>d</i> - {@code v}| &lt; |<i>d'</i> - {@code v}|
+     *         (<i>d'</i> is farther)
+     *         <li> |<i>d</i> - {@code v}| = |<i>d'</i> - {@code v}| and
+     *         <i>c</i> is even while <i>c'</i> is odd (tie-breaking rule when
+     *         <i>d</i> and <i>d'</i> are equally close to {@code v})
+     *     </ul>
+     * </ul>
      *
-     * </ul>
-     * </ul>
-     * How many digits must be printed for the fractional part of
-     * <i>m</i> or <i>a</i>? There must be at least one digit
-     * to represent the fractional part, and beyond that as many, but
-     * only as many, more digits as are needed to uniquely distinguish
-     * the argument value from adjacent values of type
-     * {@code float}. That is, suppose that <i>x</i> is the
-     * exact mathematical value represented by the decimal
-     * representation produced by this method for a finite nonzero
-     * argument <i>f</i>. Then <i>f</i> must be the {@code float}
-     * value nearest to <i>x</i>; or, if two {@code float} values are
-     * equally close to <i>x</i>, then <i>f</i> must be one of
-     * them and the least significant bit of the significand of
-     * <i>f</i> must be {@code 0}.
+     * <p>The selected decimal <i>d</i> is then formatted as a string.
+     * If <i>d</i> &lt; 0, the first character of the string is the sign
+     * '{@code -}'. Let |<i>d</i>| = <i>m</i>&middot;10<sup><i>k</i></sup>,
+     * for the unique pair of integer <i>k</i> and real <i>m</i> meeting
+     * 1 &le; <i>m</i> &lt; 10. Also, let the decimal expansion of <i>m</i> be
+     * <i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub>&thinsp;<!--
+     * -->&hellip;&thinsp;<i>m</i><sub><i>i</i></sub>,
+     * with <i>i</i> &ge; 1 and <i>m</i><sub><i>i</i></sub> &ne; 0.
+     * <ul>
+     *     <li>Case -3 &le; k &lt; 0: |<i>d</i>| is formatted as
+     *     0&thinsp;.&thinsp;0&hellip;0<i>m</i><sub>1</sub>&hellip;<!--
+     *     --><i>m</i><sub><i>i</i></sub>,
+     *     where there are exactly -<i>k</i> leading zeroes before
+     *     <i>m</i><sub>1</sub>, including the zero to the left of the
+     *     decimal point; for example, {@code "0.01234"}.
+     *     <li>Case 0 &le; <i>k</i> &lt; 7:
+     *     <ul>
+     *         <li>Subcase <i>i</i> &lt; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>0&hellip;0&thinsp;.&thinsp;0,
+     *         where there are exactly <i>k</i> + 2 - <i>i</i> trailing zeroes
+     *         after <i>m</i><sub><i>i</i></sub>, including the zero to the
+     *         right of the decimal point; for example, {@code "1200.0"}.
+     *         <li>Subcase <i>i</i> &ge; <i>k</i> + 2:
+     *         |<i>d</i>| is formatted as <i>m</i><sub>1</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>k</i>+1</sub>&thinsp;.&thinsp;<!--
+     *         --><i>m</i><sub><i>k</i>+2</sub>&hellip;<!--
+     *         --><i>m</i><sub><i>i</i></sub>; for example, {@code "1234.32"}.
+     *     </ul>
+     *     <li>Case <i>k</i> &lt; -3 or <i>k</i> &ge; 7:
+     *     computerized scientific notation is used to format |<i>d</i>|,
+     *     by combining <i>m</i> and <i>k</i> separated by the exponent
+     *     indicator '{@code E}'. The exponent <i>k</i> is formatted as in
+     *     {@link Integer#toString(int)}.
+     *     <ul>
+     *         <li>Subcase <i>i</i> = 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;0E<i>k</i>;
+     *         for example, {@code "2.0E23"}.
+     *         <li>Subcase <i>i</i> &gt; 1: |<i>d</i>| is formatted as
+     *         <i>m</i><sub>1</sub>&thinsp;.&thinsp;<i>m</i><sub>2</sub><!--
+     *         -->&hellip;<i>m</i><sub><i>i</i></sub>E<i>k</i>;
+     *         for example, {@code "1.234E-32"}.
+     *     </ul>
+     *  </ul>
      *
-     * <p>To create localized string representations of a floating-point
-     * value, use subclasses of {@link java.text.NumberFormat}.
-     *
-     * @param   f   the float to be converted.
-     * @return a string representation of the argument.
+     * @param  v the {@code float} to be rendered.
+     * @return a string rendering of the argument.
      */
-    public static String toString(float f) {
-        return FloatingDecimal.toJavaFormatString(f);
+    public static String toString(float v) {
+        return FloatToDecimal.toString(v);
     }
 
     /**
diff --git a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
@@ -0,0 +1,409 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+import static java.lang.Double.*;
+import static java.lang.Long.numberOfLeadingZeros;
+import static java.lang.Math.multiplyHigh;
+import static jdk.internal.math.MathUtils.*;
+
+/**
+ * This class exposes a method to render a {@code double} as a string.
+
+ * @author Raffaello Giulietti
+ */
+final public class DoubleToDecimal {
+
+    // Precision of normal values in bits.
+    private static final int P = 53;
+
+    // Length in bits of the exponent field.
+    private static final int W = (Double.SIZE - 1) - (P - 1);
+
+    // Minimum value of the exponent.
+    private static final int Q_MIN = (-1 << W - 1) - P + 3;
+
+    // Minimum value of the coefficient of a normal value.
+    private static final long C_MIN = 1L << P - 1;
+
+    // Mask to extract the IEEE 754-2008 biased exponent.
+    private static final int BQ_MASK = (1 << W) - 1;
+
+    // Mask to extract the IEEE 754-2008 fraction bits.
+    private static final long T_MASK = (1L << P - 1) - 1;
+
+    // H = min {n integer | 10^(n-1) > 2^P}
+    private static final int H = 17;
+
+    // used in the left-to-right extraction of the digits
+    private static final int LTR = 28;
+    private static final int MASK_LTR = (1 << LTR) - 1;
+
+    private static final long MASK_63 = (1L << Long.SIZE - 1) - 1;
+
+    // for thread-safety, each thread gets its own instance of this class
+    private static final ThreadLocal<DoubleToDecimal> threadLocal =
+            ThreadLocal.withInitial(DoubleToDecimal::new);
+
+    /*
+    Room for the longer of the forms
+        -ddddd.dddddddddddd         H + 2 characters
+        -0.00ddddddddddddddddd      H + 5 characters
+        -d.ddddddddddddddddE-eee    H + 7 characters
+    where there are H digits d
+     */
+    private final char[] buf = new char[H + 7];
+
+    // index of rightmost valid character
+    private int index;
+
+    private DoubleToDecimal() {
+    }
+
+    /*
+    See Double::toString for javadoc.
+     */
+    public static String toString(double v) {
+        return threadLocalInstance().toDecimal(v);
+    }
+
+    private static DoubleToDecimal threadLocalInstance() {
+        return threadLocal.get();
+    }
+
+    private String toDecimal(double v) {
+        long bits = doubleToRawLongBits(v);
+        int bq = (int) (bits >>> P - 1) & BQ_MASK;
+        if (bq < BQ_MASK) {
+            index = -1;
+            if (bits < 0) {
+                append('-');
+            }
+            if (bq > 0) {
+                return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK);
+            }
+            if (bits == 0x0000_0000_0000_0000L) {
+                return "0.0";
+            }
+            if (bits == 0x8000_0000_0000_0000L) {
+                return "-0.0";
+            }
+            return toDecimal(Q_MIN, bits & T_MASK);
+        }
+        if (v != v) {
+            return "NaN";
+        }
+        if (v == POSITIVE_INFINITY) {
+            return "Infinity";
+        }
+        return "-Infinity";
+    }
+
+    // Let v = c * 2^q be the absolute value of the original double. Renders v.
+    private String toDecimal(int q, long c) {
+        /*
+        out = 0, if the boundaries of the rounding interval are included
+        out = 1, if they are excluded
+        d = 1 for even, d = 2 for uneven spacing around v.
+        v = cb * 2^qb
+        predecessor(v) = cbl * 2^qb
+        successor(v) = cbr * 2^qb
+         */
+        int out = (int) c & 0x1;
+
+        long cb;
+        long cbr;
+        long cbl;
+        int k;
+        int ord2alpha;
+        if (c != C_MIN | q == Q_MIN) {
+            cb = c << 1;
+            cbr = cb + 1;
+            k = flog10pow2(q);
+            ord2alpha = q + flog2pow10(-k) + 1;
+        } else {
+            cb = c << 2;
+            cbr = cb + 2;
+            k = flog10threeQuartersPow2(q);
+            ord2alpha = q + flog2pow10(-k);
+        }
+        cbl = cb - 1;
+        long mask = (1L << 63 - ord2alpha) - 1;
+        long threshold = 1L << 62 - ord2alpha;
+
+        // pow5 = pow51*2^63 + pow50
+        long pow51 = ceilPow5dHigh(-k);
+        long pow50 = ceilPow5dLow(-k);
+
+        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
+        long x0 = pow50 * cb;
+        long x1 = multiplyHigh(pow50, cb);
+        long y0 = pow51 * cb;
+        long y1 = multiplyHigh(pow51, cb);
+        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        long p0 = x0 & MASK_63;
+        long p1 = z & MASK_63;
+        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vn |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbl
+        x0 = pow50 * cbl;
+        x1 = multiplyHigh(pow50, cbl);
+        y0 = pow51 * cbl;
+        y1 = multiplyHigh(pow51, cbl);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnl |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbr
+        x0 = pow50 * cbr;
+        x1 = multiplyHigh(pow50, cbr);
+        y0 = pow51 * cbr;
+        y1 = multiplyHigh(pow51, cbr);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnr |= 1;
+        }
+
+        long s = vn >> 2;
+        if (s >= 100) {
+            long s10 = s - s % 10;
+            long t10 = s10 + 10;
+            boolean uin10 = vnl + out <= s10 << 1;
+            boolean win10 = (t10 << 1) + out <= vnr;
+            if (uin10 | win10) {
+                if (!win10) {
+                    return toChars(s10, k);
+                }
+                if (!uin10) {
+                    return toChars(t10, k);
+                }
+            }
+        } else if (s < 10) {
+            /*
+            Special cases that need to be made artificially longer to meet
+            the specification
+             */
+            switch ((int) s) {
+                case 4: return toChars(49, -325); // 4.9 * 10^-324
+                case 9: return toChars(99, -325); // 9.9 * 10^-324
+            }
+        }
+        long t = s + 1;
+        boolean uin = vnl + out <= s << 1;
+        boolean win = (t << 1) + out <= vnr;
+        if (!win) {
+            return toChars(s, k);
+        }
+        if (!uin) {
+            return toChars(t, k);
+        }
+        long cmp = vn - (s + t << 1);
+        if (cmp < 0) {
+            return toChars(s, k);
+        }
+        if (cmp > 0) {
+            return toChars(t, k);
+        }
+        if ((s & 1) == 0) {
+            return toChars(s, k);
+        }
+        return toChars(t, k);
+    }
+
+    /*
+    The method formats the number f * 10^e
+
+    Division is avoided altogether by replacing it with multiplications
+    and shifts. This has a noticeable impact on performance.
+    For more in-depth readings, see for example
+    * Moeller & Granlund, "Improved division by invariant integers"
+    * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned
+        Division by Constants"
+
+    Also, once the quotient is known, the remainder is computed indirectly.
+     */
+    private String toChars(long f, int e) {
+        // Normalize f to lie in the f-independent interval [10^(H-1), 10^H)
+        int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f));
+        if (f >= pow10[len10]) {
+            len10 += 1;
+        }
+        // 10^(len10-1) <= f < 10^len10
+        f *= pow10[H - len10];
+        e += len10;
+
+        /*
+        Split the H = 17 digits of f into:
+            h = the most significant digit of f
+            m = the next 8 most significant digits of f
+            l = the last 8, least significant digits of f
+
+        Pictorially, the selected decimal to format as String is
+            0.hmmmmmmmmllllllll * 10^e
+        Depending on the value of e, plain or computerized scientific notation
+        is used.
+         */
+        long hm = multiplyHigh(f, 48_357_032_784_585_167L) >>> 18;
+        int l = (int) (f - 100_000_000L * hm);
+        int h = (int) (hm * 1_441_151_881L >>> 57);
+        int m = (int) (hm - 100_000_000 * h);
+
+        /*
+        The left-to-right digits generation in toChars_* is inspired by
+        * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion"
+         */
+        if (0 < e && e <= 7) {
+            return toChars_1(h, m, l, e);
+        }
+        if (-3 < e && e <= 0) {
+            return toChars_2(h, m, l, e);
+        }
+        return toChars_3(h, m, l, e);
+    }
+
+    // 0 < e <= 7: plain format without leading zeroes.
+    private String toChars_1(int h, int m, int l, int e) {
+        appendDigit(h);
+        // y = (m + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh(
+                (long) (m + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        int t;
+        int i = 1;
+        for (; i < e; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        append('.');
+        for (; i <= 8; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        lowDigits(l);
+        return charsToString();
+    }
+
+    // -3 < e <= 0: plain format with leading zeroes.
+    private String toChars_2(int h, int m, int l, int e) {
+        appendDigit(0);
+        append('.');
+        for (; e < 0; ++e) {
+          appendDigit(0);
+        }
+        appendDigit(h);
+        append8Digits(m);
+        lowDigits(l);
+        return charsToString();
+    }
+
+    // -3 >= e | e > 7: computerized scientific notation
+    private String toChars_3(int h, int m, int l, int e) {
+        appendDigit(h);
+        append('.');
+        append8Digits(m);
+        lowDigits(l);
+        exponent(e - 1);
+        return charsToString();
+    }
+
+    private void lowDigits(int l) {
+        if (l != 0) {
+            append8Digits(l);
+        }
+        removeTrailingZeroes();
+    }
+
+    private void append8Digits(int v) {
+        // y = (v + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh((long) (v + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        for (int i = 0; i < 8; ++i) {
+            int t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+    }
+
+    private void removeTrailingZeroes() {
+        while (buf[index] == '0') {
+            --index;
+        }
+        if (buf[index] == '.') {
+            ++index;
+        }
+    }
+
+    private void exponent(int e) {
+        append('E');
+        if (e < 0) {
+            append('-');
+            e = -e;
+        }
+        if (e < 10) {
+            appendDigit(e);
+            return;
+        }
+        if (e < 100) {
+            // d = e / 10
+            int d = e * 205 >>> 11;
+            appendDigit(d);
+            appendDigit(e - 10 * d);
+            return;
+        }
+        // d = e / 100
+        int d = e * 1_311 >>> 17;
+        appendDigit(d);
+        e -= 100 * d;
+        // d = e / 10
+        d = e * 205 >>> 11;
+        appendDigit(d);
+        appendDigit(e - 10 * d);
+    }
+
+    private void append(int c) {
+        buf[++index] = (char) c;
+    }
+
+    private void appendDigit(int d) {
+        buf[++index] = (char) ('0' + d);
+    }
+
+    private String charsToString() {
+        return new String(buf, 0, index + 1);
+    }
+
+}
diff --git a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
@@ -0,0 +1,393 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+import static java.lang.Float.*;
+import static java.lang.Long.numberOfLeadingZeros;
+import static java.lang.Math.multiplyHigh;
+import static jdk.internal.math.MathUtils.*;
+
+/**
+ * This class exposes a method to render a {@code float} as a string.
+
+ * @author Raffaello Giulietti
+ */
+final public class FloatToDecimal {
+
+    // Precision of normal values in bits.
+    private static final int P = 24;
+
+    // Length in bits of the exponent field.
+    private static final int W = (Float.SIZE - 1) - (P - 1);
+
+    // Minimum value of the exponent.
+    private static final int Q_MIN = (-1 << W - 1) - P + 3;
+
+    // Minimum value of the coefficient of a normal value.
+    private static final int C_MIN = 1 << P - 1;
+
+    // Mask to extract the IEEE 754-2008 biased exponent.
+    private static final int BQ_MASK = (1 << W) - 1;
+
+    // Mask to extract the IEEE 754-2008 fraction bits.
+    private static final int T_MASK = (1 << P - 1) - 1;
+
+    // H = min {n integer | 10^(n-1) > 2^P}
+    private static final int H = 9;
+
+    // used in the left-to-right extraction of the digits
+    private static final int LTR = 28;
+    private static final int MASK_LTR = (1 << LTR) - 1;
+
+    private static final long MASK_63 = (1L << Long.SIZE - 1) - 1;
+
+    // for thread-safety, each thread gets its own instance of this class
+    private static final ThreadLocal<FloatToDecimal> threadLocal =
+            ThreadLocal.withInitial(FloatToDecimal::new);
+
+    /*
+    Room for the longer of the forms
+        -ddddd.dddd         H + 2 characters
+        -0.00ddddddddd      H + 5 characters
+        -d.ddddddddE-ee     H + 6 characters
+    where there are H digits d
+     */
+    private final char[] buf = new char[H + 6];
+
+    // index of rightmost valid character
+    private int index;
+
+    private FloatToDecimal() {
+    }
+
+    /*
+    See Float::toString for javadoc.
+     */
+    public static String toString(float v) {
+        return threadLocalInstance().toDecimal(v);
+    }
+
+    private static FloatToDecimal threadLocalInstance() {
+        return threadLocal.get();
+    }
+
+    private String toDecimal(float v) {
+        int bits = floatToRawIntBits(v);
+        int bq = (bits >>> P - 1) & BQ_MASK;
+        if (bq < BQ_MASK) {
+            index = -1;
+            if (bits < 0) {
+                append('-');
+            }
+            if (bq > 0) {
+                return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK);
+            }
+            if (bits == 0x0000_0000) {
+                return "0.0";
+            }
+            if (bits == 0x8000_0000) {
+                return "-0.0";
+            }
+            return toDecimal(Q_MIN, bits & T_MASK);
+        }
+        if (v != v) {
+            return "NaN";
+        }
+        if (v == POSITIVE_INFINITY) {
+            return "Infinity";
+        }
+        return "-Infinity";
+    }
+
+    // Let v = c * 2^q be the absolute value of the original float. Renders v.
+    private String toDecimal(int q, int c) {
+        /*
+        out = 0, if the boundaries of the rounding interval are included
+        out = 1, if they are excluded
+        d = 1 for even, d = 2 for uneven spacing around v.
+        v = cb * 2^qb
+        predecessor(v) = cbl * 2^qb
+        successor(v) = cbr * 2^qb
+         */
+        int out = c & 0x1;
+
+        long cb;
+        long cbr;
+        long cbl;
+        int k;
+        int ord2alpha;
+        if (c != C_MIN | q == Q_MIN) {
+            cb = c << 1;
+            cbr = cb + 1;
+            k = flog10pow2(q);
+            ord2alpha = q + flog2pow10(-k) + 1;
+        } else {
+            cb = c << 2;
+            cbr = cb + 2;
+            k = flog10threeQuartersPow2(q);
+            ord2alpha = q + flog2pow10(-k);
+        }
+        cbl = cb - 1;
+        long mask = (1L << 63 - ord2alpha) - 1;
+        long threshold = 1L << 62 - ord2alpha;
+
+        // pow5 = pow51*2^63 + pow50
+        long pow51 = ceilPow5dHigh(-k);
+        long pow50 = ceilPow5dLow(-k);
+
+        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
+        long x0 = pow50 * cb;
+        long x1 = multiplyHigh(pow50, cb);
+        long y0 = pow51 * cb;
+        long y1 = multiplyHigh(pow51, cb);
+        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        long p0 = x0 & MASK_63;
+        long p1 = z & MASK_63;
+        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vn |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbl
+        x0 = pow50 * cbl;
+        x1 = multiplyHigh(pow50, cbl);
+        y0 = pow51 * cbl;
+        y1 = multiplyHigh(pow51, cbl);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnl |= 1;
+        }
+
+        // Similarly as above, with p = pow5 * cbr
+        x0 = pow50 * cbr;
+        x1 = multiplyHigh(pow50, cbr);
+        y0 = pow51 * cbr;
+        y1 = multiplyHigh(pow51, cbr);
+        z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
+        p0 = x0 & MASK_63;
+        p1 = z & MASK_63;
+        p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
+        long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha;
+        if ((p1 & mask) != 0 || p0 >= threshold) {
+            vnr |= 1;
+        }
+
+        long s = vn >> 2;
+        if (s >= 100) {
+            long s10 = s - s % 10;
+            long t10 = s10 + 10;
+            boolean uin10 = vnl + out <= s10 << 1;
+            boolean win10 = (t10 << 1) + out <= vnr;
+            if (uin10 | win10) {
+                if (!win10) {
+                    return toChars(s10, k);
+                }
+                if (!uin10) {
+                    return toChars(t10, k);
+                }
+            }
+        } else if (s < 10) {
+            /*
+            Special cases that need to be made artificially longer to meet
+            the specification
+             */
+            switch ((int) s) {
+                case 1: return toChars(14, -46); // 1.4 * 10^-45
+                case 2: return toChars(28, -46); // 2.8 * 10^-45
+                case 4: return toChars(42, -46); // 4.2 * 10^-45
+                case 5: return toChars(56, -46); // 5.6 * 10^-45
+                case 7: return toChars(70, -46); // 7.0 * 10^-45
+                case 8: return toChars(84, -46); // 8.4 * 10^-45
+                case 9: return toChars(98, -46); // 9.8 * 10^-45
+            }
+        }
+        long t = s + 1;
+        boolean uin = vnl + out <= s << 1;
+        boolean win = (t << 1) + out <= vnr;
+        if (!win) {
+            return toChars(s, k);
+        }
+        if (!uin) {
+            return toChars(t, k);
+        }
+        long cmp = vn - (s + t << 1);
+        if (cmp < 0) {
+            return toChars(s, k);
+        }
+        if (cmp > 0) {
+            return toChars(t, k);
+        }
+        if ((s & 1) == 0) {
+            return toChars(s, k);
+        }
+        return toChars(t, k);
+    }
+
+    /*
+    The method formats the number f * 10^e
+
+    Division is avoided altogether by replacing it with multiplications
+    and shifts. This has a noticeable impact on performance.
+    For more in-depth readings, see for example
+    * Moeller & Granlund, "Improved division by invariant integers"
+    * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned
+        Division by Constants"
+
+    Also, once the quotient is known, the remainder is computed indirectly.
+     */
+    private String toChars(long f, int e) {
+        // Normalize f to lie in the f-independent interval [10^(H-1), 10^H)
+        int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f));
+        if (f >= pow10[len10]) {
+            len10 += 1;
+        }
+        // 10^(len10-1) <= f < 10^len10
+        f *= pow10[H - len10];
+        e += len10;
+
+        /*
+        Split the H = 9 digits of f into:
+            h = the most significant digit of f
+            l = the last 8, least significant digits of f
+
+        Pictorially, the selected decimal to format as String is
+            0.hllllllll * 10^e
+        Depending on the value of e, plain or computerized scientific notation
+        is used.
+         */
+        int h = (int) (f * 1_441_151_881L >>> 57);
+        int l = (int) (f - 100_000_000 * h);
+
+        /*
+        The left-to-right digits generation in toChars_* is inspired by
+        * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion"
+         */
+        if (0 < e && e <= 7) {
+            return toChars_1(h, l, e);
+        }
+        if (-3 < e && e <= 0) {
+            return toChars_2(h, l, e);
+        }
+        return toChars_3(h, l, e);
+    }
+
+    // 0 < e <= 7: plain format without leading zeroes.
+    private String toChars_1(int h, int l, int e) {
+        appendDigit(h);
+        // y = (l + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh(
+                (long) (l + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        int t;
+        int i = 1;
+        for (; i < e; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        append('.');
+        for (; i <= 8; ++i) {
+            t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+        removeTrailingZeroes();
+        return charsToString();
+    }
+
+    // -3 < e <= 0: plain format with leading zeroes.
+    private String toChars_2(int h, int l, int e) {
+        appendDigit(0);
+        append('.');
+        for (; e < 0; ++e) {
+          appendDigit(0);
+        }
+        appendDigit(h);
+        append8Digits(l);
+        removeTrailingZeroes();
+        return charsToString();
+    }
+
+    // -3 >= e | e > 7: computerized scientific notation
+    private String toChars_3(int h, int l, int e) {
+        appendDigit(h);
+        append('.');
+        append8Digits(l);
+        removeTrailingZeroes();
+        exponent(e - 1);
+        return charsToString();
+    }
+
+    private void append8Digits(int v) {
+        // y = (v + 1) * 2^LTR / 100_000_000 - 1;
+        int y = (int) (multiplyHigh((long) (v + 1) << LTR,
+                48_357_032_784_585_167L) >>> 18) - 1;
+        for (int i = 0; i < 8; ++i) {
+            int t = 10 * y;
+            appendDigit(t >>> LTR);
+            y = t & MASK_LTR;
+        }
+    }
+
+    private void removeTrailingZeroes() {
+        while (buf[index] == '0') {
+            --index;
+        }
+        if (buf[index] == '.') {
+            ++index;
+        }
+    }
+
+    private void exponent(int e) {
+        append('E');
+        if (e < 0) {
+            append('-');
+            e = -e;
+        }
+        if (e < 10) {
+            appendDigit(e);
+            return;
+        }
+        // d = e / 10
+        int d = e * 205 >>> 11;
+        appendDigit(d);
+        appendDigit(e - 10 * d);
+    }
+
+    private void append(int c) {
+        buf[++index] = (char) c;
+    }
+
+    private void appendDigit(int d) {
+        buf[++index] = (char) ('0' + d);
+    }
+
+    private String charsToString() {
+        return new String(buf, 0, index + 1);
+    }
+
+}
diff --git a/src/java.base/share/classes/jdk/internal/math/MathUtils.java b/src/java.base/share/classes/jdk/internal/math/MathUtils.java
new file mode 100644
--- /dev/null
+++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java
@@ -0,0 +1,775 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+package jdk.internal.math;
+
+/**
+ * @author Raffaello Giulietti
+ */
+final class MathUtils {
+
+    // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10)
+    private static final int Q_10 = 41;
+    private static final long C_10 = 661_971_961_083L;
+    private static final long A_10 = -274_743_187_321L;
+
+    // C_2 = floor(log2(10) * 2^Q_2)
+    private static final int Q_2 = 38;
+    private static final long C_2 = 913_124_641_741L;
+
+    // The minimum exponent for ceilPow5dHigh(int)
+    private static final int MIN_EXP = -292;
+
+    private MathUtils() {
+    }
+
+    // pow10[i] = 10^i, 0 <= i <= H
+    static final long[] pow10 = {
+        1L,
+        10L,
+        100L,
+        1_000L,
+        10_000L,
+        100_000L,
+        1_000_000L,
+        10_000_000L,
+        100_000_000L,
+        1_000_000_000L,
+        10_000_000_000L,
+        100_000_000_000L,
+        1_000_000_000_000L,
+        10_000_000_000_000L,
+        100_000_000_000_000L,
+        1_000_000_000_000_000L,
+        10_000_000_000_000_000L,
+        100_000_000_000_000_000L,
+    };
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 10<sup><i>k</i></sup> &le; 2<sup>{@code e}</sup>
+     * &lt; 10<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when |{@code e}| &le; 5_456_721.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 2, which should meet
+     *          |{@code e}| &le; 5_456_721 for safe results.
+     * @return &lfloor;log<sub>10</sub>2<sup>{@code e}</sup>&rfloor;.
+     */
+    static int flog10pow2(int e) {
+        return (int) (e * C_10 >> Q_10);
+    }
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 10<sup><i>k</i></sup> &le; 3/4 &middot; 2<sup>{@code e}</sup>
+     * &lt; 10<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when
+     * -2_956_395 &le; |{@code e}| &le; 2_500_325.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 2, which should meet
+     *          -2_956_395 &le; |{@code e}| &le; 2_500_325 for safe results.
+     * @return &lfloor;log<sub>10</sub>(3/4 &middot;
+     * 2<sup>{@code e}</sup>)&rfloor;.
+     */
+    static int flog10threeQuartersPow2(int e) {
+        return (int) ((e * C_10 + A_10) >> Q_10);
+    }
+
+    /**
+     * Returns the unique integer <i>k</i> such that
+     * 2<sup><i>k</i></sup> &le; 10<sup>{@code e}</sup>
+     * &lt; 2<sup><i>k</i>+1</sup>.
+     * <p>
+     * The result is correct when |{@code e}| &le; 1_838_394.
+     * Otherwise the result may or may not be correct.
+     *
+     * @param e The exponent of 10, which should meet
+     *          |{@code e}| &le; 1_838_394 for safe results.
+     * @return &lfloor;log<sub>2</sub>10<sup>{@code e}</sup>&rfloor;.
+     */
+    static int flog2pow10(int e) {
+        return (int) (e * C_2 >> Q_2);
+    }
+
+    /**
+     * Let 5<sup>{@code e}</sup> = <i>d</i> &middot; 2<sup><i>r</i></sup>,
+     * for the unique pair of integer <i>r</i> and real <i>d</i> meeting
+     * 2<sup>125</sup> &le; d &lt; 2<sup>126</sup>.
+     * Further, let <i>c</i> = &lceil;<i>d</i>&rceil;.
+     * Split <i>c</i> into the higher 63 bits <i>c</i><sub>1</sub> and
+     * the lower 63 bits <i>c</i><sub>0</sub>. Thus,
+     * <i>c</i><sub>1</sub> =
+     * &lfloor;<i>c</i> &middot; 2<sup>-63</sup>&rfloor;
+     * and
+     * <i>c</i><sub>0</sub> =
+     * <i>c</i> - <i>c</i><sub>1</sub> &middot; 2<sup>63</sup>.
+     * <p>
+     * This method returns <i>c</i><sub>1</sub> while
+     * {@link #ceilPow5dLow(int)} returns <i>c</i><sub>0</sub>.
+     * <p>
+     * If needed, the exponent <i>r</i> can be computed as
+     * <i>r</i> = {@code flog2pow10(e) - e - 125}
+     * (see {@link #flog2pow10(int)}).
+     *
+     * @param e The exponent of 5,
+     *          which must meet -292 &le; {@code e} &le; 324.
+     * @return <i>c</i><sub>1</sub> as described above.
+     */
+    static long ceilPow5dHigh(int e) {
+        return ceilPow5d[e - MIN_EXP << 1];
+    }
+
+    /**
+     * Returns <i>c</i><sub>0</sub> as described in {@link #ceilPow5dHigh(int)}.
+     *
+     * @param e The exponent of 5,
+     *          which must meet -292 &le; {@code e} &le; 324.
+     * @return <i>c</i><sub>0</sub> as described in {@link #ceilPow5dHigh(int)}.
+     */
+    static long ceilPow5dLow(int e) {
+        return ceilPow5d[e - MIN_EXP << 1 | 1];
+    }
+
+    private static final long[] ceilPow5d = {
+        /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL,
+        /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL,
+        /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L,
+        /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L,
+        /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL,
+        /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L,
+        /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L,
+        /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL,
+        /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L,
+        /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL,
+        /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL,
+        /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L,
+        /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL,
+        /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L,
+        /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L,
+        /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL,
+        /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L,
+        /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L,
+        /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L,
+        /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL,
+        /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L,
+        /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L,
+        /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L,
+        /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL,
+        /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L,
+        /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L,
+        /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL,
+        /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L,
+        /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L,
+        /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L,
+        /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L,
+        /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL,
+        /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL,
+        /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L,
+        /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L,
+        /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL,
+        /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L,
+        /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L,
+        /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L,
+        /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L,
+        /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L,
+        /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L,
+        /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL,
+        /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L,
+        /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L,
+        /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L,
+        /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L,
+        /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L,
+        /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L,
+        /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L,
+        /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L,
+        /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L,
+        /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL,
+        /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L,
+        /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L,
+        /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL,
+        /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L,
+        /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL,
+        /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L,
+        /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L,
+        /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL,
+        /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L,
+        /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L,
+        /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L,
+        /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL,
+        /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L,
+        /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L,
+        /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L,
+        /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL,
+        /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L,
+        /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L,
+        /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L,
+        /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L,
+        /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL,
+        /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L,
+        /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L,
+        /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL,
+        /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L,
+        /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L,
+        /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L,
+        /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L,
+        /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L,
+        /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L,
+        /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL,
+        /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL,
+        /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L,
+        /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L,
+        /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL,
+        /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL,
+        /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L,
+        /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L,
+        /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL,
+        /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L,
+        /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L,
+        /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L,
+        /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L,
+        /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL,
+        /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L,
+        /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L,
+        /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L,
+        /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L,
+        /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L,
+        /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L,
+        /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L,
+        /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L,
+        /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L,
+        /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L,
+        /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L,
+        /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L,
+        /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L,
+        /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L,
+        /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L,
+        /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL,
+        /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L,
+        /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL,
+        /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL,
+        /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L,
+        /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L,
+        /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L,
+        /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L,
+        /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L,
+        /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L,
+        /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L,
+        /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L,
+        /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L,
+        /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL,
+        /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL,
+        /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L,
+        /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL,
+        /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L,
+        /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L,
+        /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL,
+        /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L,
+        /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL,
+        /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL,
+        /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL,
+        /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL,
+        /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L,
+        /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL,
+        /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L,
+        /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL,
+        /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L,
+        /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L,
+        /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL,
+        /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL,
+        /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL,
+        /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L,
+        /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL,
+        /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L,
+        /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL,
+        /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L,
+        /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L,
+        /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL,
+        /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L,
+        /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L,
+        /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL,
+        /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L,
+        /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L,
+        /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L,
+        /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL,
+        /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL,
+        /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL,
+        /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L,
+        /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL,
+        /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L,
+        /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL,
+        /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L,
+        /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL,
+        /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL,
+        /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L,
+        /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L,
+        /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL,
+        /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL,
+        /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL,
+        /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L,
+        /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL,
+        /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL,
+        /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L,
+        /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L,
+        /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L,
+        /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L,
+        /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L,
+        /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L,
+        /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L,
+        /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL,
+        /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L,
+        /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL,
+        /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L,
+        /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L,
+        /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L,
+        /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL,
+        /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL,
+        /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL,
+        /*  -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L,
+        /*  -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL,
+        /*  -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL,
+        /*  -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L,
+        /*  -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L,
+        /*  -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L,
+        /*  -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L,
+        /*  -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L,
+        /*  -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL,
+        /*  -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L,
+        /*  -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL,
+        /*  -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL,
+        /*  -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL,
+        /*  -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L,
+        /*  -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL,
+        /*  -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL,
+        /*  -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL,
+        /*  -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL,
+        /*  -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L,
+        /*  -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L,
+        /*  -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L,
+        /*  -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL,
+        /*  -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L,
+        /*  -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL,
+        /*  -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L,
+        /*  -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L,
+        /*  -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL,
+        /*  -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL,
+        /*  -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L,
+        /*  -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L,
+        /*  -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL,
+        /*  -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L,
+        /*  -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L,
+        /*  -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L,
+        /*  -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL,
+        /*  -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL,
+        /*  -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL,
+        /*  -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL,
+        /*  -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L,
+        /*  -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L,
+        /*  -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L,
+        /*  -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L,
+        /*  -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL,
+        /*  -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L,
+        /*  -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL,
+        /*  -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L,
+        /*  -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL,
+        /*  -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL,
+        /*  -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL,
+        /*  -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L,
+        /*  -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL,
+        /*  -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L,
+        /*  -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL,
+        /*  -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL,
+        /*  -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L,
+        /*  -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL,
+        /*  -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L,
+        /*  -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L,
+        /*  -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L,
+        /*  -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L,
+        /*  -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L,
+        /*  -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L,
+        /*  -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L,
+        /*  -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL,
+        /*  -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL,
+        /*  -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L,
+        /*  -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L,
+        /*  -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL,
+        /*  -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L,
+        /*  -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L,
+        /*  -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL,
+        /*  -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L,
+        /*  -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L,
+        /*  -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L,
+        /*  -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L,
+        /*  -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L,
+        /*  -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L,
+        /*  -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL,
+        /*  -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L,
+        /*  -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L,
+        /*  -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL,
+        /*  -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L,
+        /*  -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L,
+        /*  -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL,
+        /*  -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L,
+        /*  -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L,
+        /*  -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL,
+        /*  -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L,
+        /*  -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L,
+        /*  -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L,
+        /*   -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL,
+        /*   -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L,
+        /*   -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L,
+        /*   -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L,
+        /*   -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L,
+        /*   -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL,
+        /*   -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL,
+        /*   -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L,
+        /*   -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L,
+        /*    0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0000L,
+        /*    9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0000L,
+        /*   14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0000L,
+        /*   15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0000L,
+        /*   16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0000L,
+        /*   17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0000L,
+        /*   18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0000L,
+        /*   19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0000L,
+        /*   20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0000L,
+        /*   21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0000L,
+        /*   22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0000L,
+        /*   23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0000L,
+        /*   24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0000L,
+        /*   25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0000L,
+        /*   26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0000L,
+        /*   27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0000L,
+        /*   28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0000L,
+        /*   29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0000L,
+        /*   30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0000L,
+        /*   31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0000L,
+        /*   32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0000L,
+        /*   33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0000L,
+        /*   34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0000L,
+        /*   35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0000L,
+        /*   36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0000L,
+        /*   37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0000L,
+        /*   38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0000L,
+        /*   39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0000L,
+        /*   40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0000L,
+        /*   41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0000L,
+        /*   42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0000L,
+        /*   43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0000L,
+        /*   44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0000L,
+        /*   45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0000L,
+        /*   46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0000L,
+        /*   47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0000L,
+        /*   48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4000L,
+        /*   49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5000L,
+        /*   50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B200L,
+        /*   51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E80L,
+        /*   52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B620L,
+        /*   53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D4L,
+        /*   54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F649L,
+        /*   55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL,
+        /*   56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL,
+        /*   57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L,
+        /*   58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L,
+        /*   59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL,
+        /*   60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L,
+        /*   61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL,
+        /*   62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL,
+        /*   63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL,
+        /*   64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL,
+        /*   65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL,
+        /*   66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL,
+        /*   67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L,
+        /*   68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L,
+        /*   69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL,
+        /*   70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L,
+        /*   71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L,
+        /*   72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L,
+        /*   73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L,
+        /*   74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L,
+        /*   75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L,
+        /*   76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L,
+        /*   77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L,
+        /*   78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL,
+        /*   79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L,
+        /*   80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L,
+        /*   81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L,
+        /*   82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L,
+        /*   83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L,
+        /*   84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL,
+        /*   85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL,
+        /*   86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L,
+        /*   87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL,
+        /*   88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L,
+        /*   89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL,
+        /*   90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L,
+        /*   91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL,
+        /*   92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L,
+        /*   93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL,
+        /*   94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L,
+        /*   95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L,
+        /*   96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L,
+        /*   97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L,
+        /*   98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L,
+        /*   99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L,
+        /*  100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L,
+        /*  101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL,
+        /*  102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L,
+        /*  103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL,
+        /*  104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L,
+        /*  105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL,
+        /*  106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL,
+        /*  107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L,
+        /*  108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L,
+        /*  109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L,
+        /*  110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L,
+        /*  111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L,
+        /*  112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL,
+        /*  113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L,
+        /*  114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L,
+        /*  115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L,
+        /*  116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L,
+        /*  117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L,
+        /*  118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL,
+        /*  119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL,
+        /*  120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL,
+        /*  121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL,
+        /*  122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L,
+        /*  123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL,
+        /*  124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L,
+        /*  125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L,
+        /*  126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L,
+        /*  127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L,
+        /*  128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL,
+        /*  129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L,
+        /*  130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL,
+        /*  131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL,
+        /*  132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL,
+        /*  133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL,
+        /*  134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L,
+        /*  135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L,
+        /*  136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL,
+        /*  137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL,
+        /*  138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L,
+        /*  139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL,
+        /*  140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL,
+        /*  141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L,
+        /*  142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL,
+        /*  143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL,
+        /*  144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL,
+        /*  145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L,
+        /*  146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L,
+        /*  147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL,
+        /*  148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L,
+        /*  149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL,
+        /*  150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL,
+        /*  151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL,
+        /*  152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL,
+        /*  153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L,
+        /*  154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL,
+        /*  155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL,
+        /*  156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L,
+        /*  157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL,
+        /*  158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L,
+        /*  159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL,
+        /*  160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L,
+        /*  161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L,
+        /*  162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L,
+        /*  163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L,
+        /*  164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL,
+        /*  165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L,
+        /*  166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL,
+        /*  167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L,
+        /*  168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L,
+        /*  169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L,
+        /*  170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL,
+        /*  171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L,
+        /*  172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L,
+        /*  173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL,
+        /*  174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL,
+        /*  175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL,
+        /*  176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L,
+        /*  177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L,
+        /*  178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL,
+        /*  179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L,
+        /*  180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L,
+        /*  181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L,
+        /*  182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L,
+        /*  183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L,
+        /*  184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL,
+        /*  185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL,
+        /*  186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL,
+        /*  187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL,
+        /*  188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL,
+        /*  189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL,
+        /*  190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L,
+        /*  191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL,
+        /*  192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L,
+        /*  193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L,
+        /*  194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL,
+        /*  195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L,
+        /*  196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L,
+        /*  197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L,
+        /*  198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL,
+        /*  199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L,
+        /*  200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L,
+        /*  201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L,
+        /*  202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL,
+        /*  203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L,
+        /*  204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL,
+        /*  205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL,
+        /*  206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L,
+        /*  207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL,
+        /*  208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L,
+        /*  209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L,
+        /*  210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL,
+        /*  211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L,
+        /*  212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L,
+        /*  213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L,
+        /*  214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL,
+        /*  215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL,
+        /*  216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L,
+        /*  217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL,
+        /*  218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L,
+        /*  219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L,
+        /*  220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L,
+        /*  221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L,
+        /*  222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L,
+        /*  223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L,
+        /*  224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL,
+        /*  225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L,
+        /*  226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L,
+        /*  227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL,
+        /*  228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L,
+        /*  229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L,
+        /*  230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL,
+        /*  231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L,
+        /*  232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L,
+        /*  233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L,
+        /*  234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L,
+        /*  235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL,
+        /*  236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL,
+        /*  237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L,
+        /*  238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L,
+        /*  239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L,
+        /*  240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL,
+        /*  241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL,
+        /*  242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL,
+        /*  243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L,
+        /*  244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL,
+        /*  245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL,
+        /*  246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL,
+        /*  247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L,
+        /*  248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L,
+        /*  249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L,
+        /*  250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L,
+        /*  251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L,
+        /*  252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L,
+        /*  253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL,
+        /*  254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L,
+        /*  255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L,
+        /*  256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL,
+        /*  257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL,
+        /*  258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L,
+        /*  259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL,
+        /*  260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L,
+        /*  261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL,
+        /*  262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L,
+        /*  263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL,
+        /*  264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L,
+        /*  265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL,
+        /*  266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L,
+        /*  267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L,
+        /*  268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL,
+        /*  269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL,
+        /*  270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL,
+        /*  271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L,
+        /*  272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L,
+        /*  273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L,
+        /*  274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L,
+        /*  275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L,
+        /*  276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L,
+        /*  277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L,
+        /*  278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL,
+        /*  279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL,
+        /*  280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL,
+        /*  281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L,
+        /*  282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL,
+        /*  283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L,
+        /*  284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L,
+        /*  285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L,
+        /*  286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L,
+        /*  287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL,
+        /*  288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L,
+        /*  289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL,
+        /*  290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L,
+        /*  291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL,
+        /*  292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL,
+        /*  293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L,
+        /*  294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL,
+        /*  295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L,
+        /*  296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L,
+        /*  297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L,
+        /*  298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL,
+        /*  299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L,
+        /*  300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L,
+        /*  301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL,
+        /*  302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L,
+        /*  303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL,
+        /*  304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL,
+        /*  305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L,
+        /*  306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L,
+        /*  307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL,
+        /*  308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L,
+        /*  309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L,
+        /*  310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L,
+        /*  311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L,
+        /*  312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L,
+        /*  313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L,
+        /*  314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL,
+        /*  315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L,
+        /*  316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL,
+        /*  317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL,
+        /*  318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L,
+        /*  319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L,
+        /*  320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L,
+        /*  321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L,
+        /*  322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L,
+        /*  323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL,
+        /*  324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L,
+    };
+
+}
diff --git a/test/jdk/java/lang/Floating/DoubleToDecString.java b/test/jdk/java/lang/Floating/DoubleToDecString.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/DoubleToDecString.java
@@ -0,0 +1,312 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.util.Random;
+
+import static java.lang.Math.*;
+import static java.lang.Double.*;
+
+/*
+ * @test
+ * @bug 8202555
+
+ * @author Raffaello Giulietti
+ */
+public class DoubleToDecString {
+
+    private static final boolean FAILURE_THROWS_EXCEPTION = true;
+
+    private static void assertTrue(boolean ok, double v, String s) {
+        if (ok) {
+            return;
+        }
+        String message = "Double::toString applied to " +
+                "Double.longBitsToDouble(" +
+                "0x" + Long.toHexString(doubleToRawLongBits(v)) + "L" +
+                ")" +
+                " returns " +
+                "\"" + s + "\"" +
+                ", which is not correct according to the specification.";
+        if (FAILURE_THROWS_EXCEPTION) {
+            throw new RuntimeException(message);
+        }
+        System.err.println(message);
+    }
+
+    private static void toDec(double v) {
+        String s = Double.toString(v);
+        assertTrue(new DoubleToStringChecker(v, s).isOK(), v, s);
+    }
+
+    private static void testExtremeValues() {
+        toDec(NEGATIVE_INFINITY);
+        toDec(-MAX_VALUE);
+        toDec(-MIN_NORMAL);
+        toDec(-MIN_VALUE);
+        toDec(-0.0);
+        toDec(0.0);
+        toDec(MIN_VALUE);
+        toDec(MIN_NORMAL);
+        toDec(MAX_VALUE);
+        toDec(POSITIVE_INFINITY);
+        toDec(NaN);
+        /*
+        Quiet NaNs have the most significant bit of the mantissa as 1,
+        while signaling NaNs have it as 0.
+        Exercise 4 combinations of quiet/signaling NaNs and
+        "positive/negative" NaNs
+         */
+        toDec(longBitsToDouble(0x7FF8_0000_0000_0001L));
+        toDec(longBitsToDouble(0x7FF0_0000_0000_0001L));
+        toDec(longBitsToDouble(0xFFF8_0000_0000_0001L));
+        toDec(longBitsToDouble(0xFFF0_0000_0000_0001L));
+    }
+
+    /*
+    A few "powers of 10" are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf10() {
+        for (int e = -323; e <= 309; ++e) {
+            toDec(parseDouble("1e" + e));
+        }
+    }
+
+    /*
+    Many powers of 2 are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf2() {
+        for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) {
+            toDec(v);
+        }
+    }
+
+    /*
+    There are tons of doubles that are rendered incorrectly by the JDK.
+    While the renderings correctly round back to the original value,
+    they are longer than needed or are not the closest decimal to the double.
+    Here are just a very few examples.
+     */
+    private static final String[] Anomalies = {
+            // JDK renders these, and others, with 18 digits!
+            "2.82879384806159E17", "1.387364135037754E18",
+            "1.45800632428665E17",
+
+            // JDK renders these longer than needed.
+            "1.6E-322", "6.3E-322",
+            "7.3879E20", "2.0E23", "7.0E22", "9.2E22",
+            "9.5E21", "3.1E22", "5.63E21", "8.41E21",
+
+            // JDK does not render these, and many others, as the closest.
+            "9.9E-324", "9.9E-323",
+            "1.9400994884341945E25", "3.6131332396758635E25",
+            "2.5138990223946153E25",
+    };
+
+    private static void testSomeAnomalies() {
+        for (String dec : Anomalies) {
+            toDec(parseDouble(dec));
+        }
+    }
+
+    /*
+    Values are from
+    Paxson V, "A Program for Testing IEEE Decimal?Binary Conversion"
+     */
+    private static final double[] PaxsonSignificands = {
+            8_511_030_020_275_656L,
+            5_201_988_407_066_741L,
+            6_406_892_948_269_899L,
+            8_431_154_198_732_492L,
+            6_475_049_196_144_587L,
+            8_274_307_542_972_842L,
+            5_381_065_484_265_332L,
+            6_761_728_585_499_734L,
+            7_976_538_478_610_756L,
+            5_982_403_858_958_067L,
+            5_536_995_190_630_837L,
+            7_225_450_889_282_194L,
+            7_225_450_889_282_194L,
+            8_703_372_741_147_379L,
+            8_944_262_675_275_217L,
+            7_459_803_696_087_692L,
+            6_080_469_016_670_379L,
+            8_385_515_147_034_757L,
+            7_514_216_811_389_786L,
+            8_397_297_803_260_511L,
+            6_733_459_239_310_543L,
+            8_091_450_587_292_794L,
+
+            6_567_258_882_077_402L,
+            6_712_731_423_444_934L,
+            6_712_731_423_444_934L,
+            5_298_405_411_573_037L,
+            5_137_311_167_659_507L,
+            6_722_280_709_661_868L,
+            5_344_436_398_034_927L,
+            8_369_123_604_277_281L,
+            8_995_822_108_487_663L,
+            8_942_832_835_564_782L,
+            8_942_832_835_564_782L,
+            8_942_832_835_564_782L,
+            6_965_949_469_487_146L,
+            6_965_949_469_487_146L,
+            6_965_949_469_487_146L,
+            7_487_252_720_986_826L,
+            5_592_117_679_628_511L,
+            8_887_055_249_355_788L,
+            6_994_187_472_632_449L,
+            8_797_576_579_012_143L,
+            7_363_326_733_505_337L,
+            8_549_497_411_294_502L,
+    };
+
+    private static final int[] PaxsonExponents = {
+            -342,
+            -824,
+             237,
+              72,
+              99,
+             726,
+            -456,
+             -57,
+             376,
+             377,
+              93,
+             710,
+             709,
+             117,
+              -1,
+            -707,
+            -381,
+             721,
+            -828,
+            -345,
+             202,
+            -473,
+
+             952,
+             535,
+             534,
+            -957,
+            -144,
+             363,
+            -169,
+            -853,
+            -780,
+            -383,
+            -384,
+            -385,
+            -249,
+            -250,
+            -251,
+             548,
+             164,
+             665,
+             690,
+             588,
+             272,
+            -448,
+    };
+
+    private static void testPaxson() {
+        for (int i = 0; i < PaxsonSignificands.length; ++i) {
+            toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i]));
+        }
+    }
+
+    /*
+    Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0.
+    These are all exact doubles.
+     */
+    private static void testLongs() {
+        for (int i = 10_000; i < 100_000; ++i) {
+            toDec(i * 1e15);
+        }
+    }
+
+    /*
+    Tests all integers up to 100_000.
+    These are all exact doubles.
+     */
+    private static void testInts() {
+        for (int i = 0; i <= 1_000_000; ++i) {
+            toDec(i);
+        }
+    }
+
+    /*
+    Random doubles over the whole range
+     */
+    private static void testRandom() {
+        Random r = new Random();
+        for (int i = 0; i < 1_000_000; ++i) {
+            toDec(longBitsToDouble(r.nextLong()));
+        }
+    }
+
+    /*
+    Random doubles over the integer range [0, 10^15).
+    These integers are all exact doubles.
+     */
+    private static void testRandomUnit() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec(r.nextLong() % 1_000_000_000_000_000L);
+        }
+    }
+
+    /*
+    Random doubles over the range [0, 10^15) as "multiples" of 1e-3
+     */
+    private static void testRandomMilli() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3);
+        }
+    }
+
+    /*
+    Random doubles over the range [0, 10^15) as "multiples" of 1e-6
+     */
+    private static void testRandomMicro() {
+        Random r = new Random();
+        for (int i = 0; i < 100_000; ++i) {
+            toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6);
+        }
+    }
+
+    public static void main(String[] args) {
+        testExtremeValues();
+        testSomeAnomalies();
+        testPowersOf2();
+        testPowersOf10();
+        testPaxson();
+        testInts();
+        testLongs();
+        testRandom();
+        testRandomUnit();
+        testRandomMilli();
+        testRandomMicro();
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/DoubleToStringChecker.java b/test/jdk/java/lang/Floating/DoubleToStringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/DoubleToStringChecker.java
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+class DoubleToStringChecker extends StringChecker {
+
+    private double v;
+
+    DoubleToStringChecker(double v, String s) {
+        super(s);
+        this.v = v;
+    }
+
+    @Override
+    BigDecimal toBigDecimal() {
+        return new BigDecimal(v);
+    }
+
+    @Override
+    boolean recovers(BigDecimal b) {
+        return b.doubleValue() == v;
+    }
+
+    @Override
+    boolean recovers(String s) {
+        return Double.parseDouble(s) == v;
+    }
+
+    @Override
+    int maxExp() {
+        return 309;
+    }
+
+    @Override
+    int minExp() {
+        return -323;
+    }
+
+    @Override
+    int maxLen10() {
+        return 17;
+    }
+
+    @Override
+    boolean isZero() {
+        return v == 0;
+    }
+
+    @Override
+    boolean isInfinity() {
+        return v == Double.POSITIVE_INFINITY;
+    }
+
+    @Override
+    void invert() {
+        v = -v;
+    }
+
+    @Override
+    boolean isNegative() {
+        return Double.doubleToRawLongBits(v) < 0;
+    }
+
+    @Override
+    boolean isNaN() {
+        return v != v;
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/FloatToDecString.java b/test/jdk/java/lang/Floating/FloatToDecString.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/FloatToDecString.java
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.util.Random;
+
+import static java.lang.Float.*;
+
+/*
+ * @test
+
+ * @author Raffaello Giulietti
+ */
+public class FloatToDecString {
+
+    private static final boolean FAILURE_THROWS_EXCEPTION = true;
+
+    private static void assertTrue(boolean ok, float v, String s) {
+        if (ok) {
+            return;
+        }
+        String message = "Float::toString applied to " +
+                "Float.intBitsToFloat(" +
+                "0x" + Integer.toHexString(floatToRawIntBits(v)) +
+                ")" +
+                " returns " +
+                "\"" + s + "\"" +
+                ", which is not correct according to the specification.";
+        if (FAILURE_THROWS_EXCEPTION) {
+            throw new RuntimeException(message);
+        }
+        System.err.println(message);
+    }
+
+    private static void toDec(float v) {
+        String s = Float.toString(v);
+        assertTrue(new FloatToStringChecker(v, s).isOK(), v, s);
+    }
+
+    /*
+    MIN_NORMAL is incorrectly rendered by the JDK.
+     */
+    private static void testExtremeValues() {
+        toDec(NEGATIVE_INFINITY);
+        toDec(-MAX_VALUE);
+        toDec(-MIN_NORMAL);
+        toDec(-MIN_VALUE);
+        toDec(-0.0f);
+        toDec(0.0f);
+        toDec(MIN_VALUE);
+        toDec(MIN_NORMAL);
+        toDec(MAX_VALUE);
+        toDec(POSITIVE_INFINITY);
+        toDec(NaN);
+        /*
+        Quiet NaNs have the most significant bit of the mantissa as 1,
+        while signaling NaNs have it as 0.
+        Exercise 4 combinations of quiet/signaling NaNs and
+        "positive/negative" NaNs.
+         */
+        toDec(intBitsToFloat(0x7FC0_0001));
+        toDec(intBitsToFloat(0x7F80_0001));
+        toDec(intBitsToFloat(0xFFC0_0001));
+        toDec(intBitsToFloat(0xFF80_0001));
+    }
+
+    /*
+    Many "powers of 10" are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf10() {
+        for (int e = -44; e <= 39; ++e) {
+            toDec(parseFloat("1e" + e));
+        }
+    }
+
+    /*
+    Many powers of 2 are incorrectly rendered by the JDK.
+    The rendering is either too long or it is not the closest decimal.
+     */
+    private static void testPowersOf2() {
+        for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) {
+            toDec(v);
+        }
+    }
+
+    /*
+    Tests all integers up to 1_000_000.
+    These are all exact floats.
+     */
+    private static void testInts() {
+        for (int i = 0; i <= 1_000_000; ++i) {
+            toDec(i);
+        }
+    }
+
+    /*
+    Random floats over the whole range.
+     */
+    private static void testRandom() {
+        Random r = new Random();
+        for (int i = 0; i < 1_000_000; ++i) {
+            toDec(intBitsToFloat(r.nextInt()));
+        }
+    }
+
+    /*
+    All, really all, possible floats. Takes between 90 and 120 minutes.
+     */
+    private static void testAll() {
+        int bits = Integer.MIN_VALUE;
+        for (; bits < Integer.MAX_VALUE; ++bits) {
+            toDec(Float.intBitsToFloat(bits));
+        }
+        toDec(Float.intBitsToFloat(bits));
+    }
+
+    public static void main(String[] args) {
+//        testAll();
+        testExtremeValues();
+        testPowersOf2();
+        testPowersOf10();
+        testInts();
+        testRandom();
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/FloatToStringChecker.java b/test/jdk/java/lang/Floating/FloatToStringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/FloatToStringChecker.java
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+class FloatToStringChecker extends StringChecker {
+
+    private float v;
+
+    FloatToStringChecker(float v, String s) {
+        super(s);
+        this.v = v;
+    }
+
+    @Override
+    BigDecimal toBigDecimal() {
+        return new BigDecimal(v);
+    }
+
+    @Override
+    boolean recovers(BigDecimal b) {
+        return b.floatValue() == v;
+    }
+
+    @Override
+    boolean recovers(String s) {
+        return Float.parseFloat(s) == v;
+    }
+
+    @Override
+    int maxExp() {
+        return 39;
+    }
+
+    @Override
+    int minExp() {
+        return -44;
+    }
+
+    @Override
+    int maxLen10() {
+        return 9;
+    }
+
+    @Override
+    boolean isZero() {
+        return v == 0;
+    }
+
+    @Override
+    boolean isInfinity() {
+        return v == Float.POSITIVE_INFINITY;
+    }
+
+    @Override
+    void invert() {
+        v = -v;
+    }
+
+    @Override
+    boolean isNegative() {
+        return Float.floatToRawIntBits(v) < 0;
+    }
+
+    @Override
+    boolean isNaN() {
+        return v != v;
+    }
+
+}
diff --git a/test/jdk/java/lang/Floating/StringChecker.java b/test/jdk/java/lang/Floating/StringChecker.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/java/lang/Floating/StringChecker.java
@@ -0,0 +1,348 @@
+/*
+ * Copyright (c) 2018, Raffaello Giulietti. 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ * This particular file is subject to the "Classpath" exception as provided
+ * in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+import java.io.IOException;
+import java.io.StringReader;
+import java.math.BigDecimal;
+
+/**
+ * @author Raffaello Giulietti
+ */
+abstract class StringChecker {
+
+    private String s;
+    private long c;
+    private int q;
+    private int len10;
+
+    StringChecker(String s) {
+        this.s = s;
+    }
+
+    /*
+    Returns whether s syntactically meets the expected output of
+    Double::toString. It is restricted to finite positive outputs.
+    It is an unusually long method but rather straightforward, too.
+    Many conditionals could be merged, but KISS here.
+     */
+    private boolean parse() {
+        try {
+            // first determine interesting boundaries in the string
+            StringReader r = new StringReader(s);
+            int ch = r.read();
+
+            int i = 0;
+            while (ch == '0') {
+                ++i;
+                ch = r.read();
+            }
+            // i is just after zeroes starting the integer
+
+            int p = i;
+            while ('0' <= ch && ch <= '9') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++p;
+                ch = r.read();
+            }
+            // p is just after digits ending the integer
+
+            int fz = p;
+            if (ch == '.') {
+                ++fz;
+                ch = r.read();
+            }
+            // fz is just after a decimal '.'
+
+            int f = fz;
+            while (ch == '0') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++f;
+                ch = r.read();
+            }
+            // f is just after zeroes starting the fraction
+
+            if (c == 0) {
+                len10 = 0;
+            }
+            int x = f;
+            while ('0' <= ch && ch <= '9') {
+                c = 10 * c + (ch - '0');
+                if (c < 0) {
+                    return false;
+                }
+                ++len10;
+                ++x;
+                ch = r.read();
+            }
+            // x is just after digits ending the fraction
+
+            int g = x;
+            if (ch == 'E') {
+                ++g;
+                ch = r.read();
+            }
+            // g is just after an exponent indicator 'E'
+
+            int ez = g;
+            if (ch == '-') {
+                ++ez;
+                ch = r.read();
+            }
+            // ez is just after a '-' sign in the exponent
+
+            int e = ez;
+            while (ch == '0') {
+                ++e;
+                ch = r.read();
+            }
+            // e is just after zeroes starting the exponent
+
+            int z = e;
+            while ('0' <= ch && ch <= '9') {
+                q = 10 * q + (ch - '0');
+                if (q < 0) {
+                    return false;
+                }
+                ++z;
+                ch = r.read();
+            }
+            // z is just after digits ending the exponent
+
+            // No other char after the number
+            if (z != s.length()) {
+                return false;
+            }
+
+            // The integer must be present
+            if (p == 0) {
+                return false;
+            }
+
+            // The decimal '.' must be present
+            if (fz == p) {
+                return false;
+            }
+
+            // The fraction must be present
+            if (x == fz) {
+                return false;
+            }
+
+            // The fraction is not 0 or it consists of exactly one 0
+            if (f == x && f - fz > 1) {
+                return false;
+            }
+
+            // Plain notation, no exponent
+            if (x == z) {
+                // At most one 0 starting the integer
+                if (i > 1) {
+                    return false;
+                }
+
+                // If the integer is 0, at most 2 zeroes start the fraction
+                if (i == 1 && f - fz > 2) {
+                    return false;
+                }
+
+                // The integer cannot have more than 7 digits
+                if (p > 7) {
+                    return false;
+                }
+
+                q = fz - x;
+
+                // OK for plain notation
+                return true;
+            }
+
+            // Computerized scientific notation
+
+            // The integer has exactly one nonzero digit
+            if (i != 0 || p != 1) {
+                return false;
+            }
+
+            //
+            // There must be an exponent indicator
+            if (x == g) {
+                return false;
+            }
+
+            // There must be an exponent
+            if (ez == z) {
+                return false;
+            }
+
+            // The exponent must not start with zeroes
+            if (ez != e) {
+                return false;
+            }
+
+            if (g != ez) {
+                q = -q;
+            }
+
+            // The exponent must not lie in [-3, 7)
+            if (-3 <= q && q < 7) {
+                return false;
+            }
+
+            q += fz - x;
+
+            // OK for computerized scientific notation
+            return true;
+        } catch (IOException ex) {
+            // An IOException on a StringReader??? Please...
+            return false;
+        }
+    }
+
+    boolean isOK() {
+        if (isNaN()) {
+            return s.equals("NaN");
+        }
+        if (isNegative()) {
+            if (s.isEmpty() || s.charAt(0) != '-') {
+                return false;
+            }
+            invert();
+            s = s.substring(1);
+        }
+        if (isInfinity()) {
+            return s.equals("Infinity");
+        }
+        if (isZero()) {
+            return s.equals("0.0");
+        }
+        if (!parse()) {
+            return false;
+        }
+        if (len10 < 2) {
+            c *= 10;
+            q -= 1;
+            len10 += 1;
+        }
+        if (2 > len10 || len10 > maxLen10()) {
+            return false;
+        }
+
+        // The exponent is bounded
+        if (minExp() > q + len10 || q + len10 > maxExp()) {
+            return false;
+        }
+
+        // s must recover v
+        try {
+            if (!recovers(s)) {
+                return false;
+            }
+        } catch (NumberFormatException e) {
+            return false;
+        }
+
+        // Get rid of trailing zeroes, still ensuring at least 2 digits
+        while (len10 > 2 && c % 10 == 0) {
+            c /= 10;
+            q += 1;
+            len10 -= 1;
+        }
+
+        if (len10 > 2) {
+            // Try with a shorter number less than v...
+            if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) {
+                return false;
+            }
+
+            // ... and with a shorter number greater than v
+            if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) {
+                return false;
+            }
+        }
+
+        // Try with the decimal predecessor...
+        BigDecimal dp = c == 10 ?
+                BigDecimal.valueOf(99, -q + 1) :
+                BigDecimal.valueOf(c - 1, -q);
+        if (recovers(dp)) {
+            BigDecimal bv = toBigDecimal();
+            BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q));
+            if (deltav.signum() >= 0) {
+                return true;
+            }
+            BigDecimal delta = dp.subtract(bv);
+            if (delta.signum() >= 0) {
+                return false;
+            }
+            int cmp = deltav.compareTo(delta);
+            return cmp > 0 || cmp == 0 && (c & 0x1) == 0;
+        }
+
+        // ... and with the decimal successor
+        BigDecimal ds = BigDecimal.valueOf(c + 1, -q);
+        if (recovers(ds)) {
+            BigDecimal bv = toBigDecimal();
+            BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q));
+            if (deltav.signum() <= 0) {
+                return true;
+            }
+            BigDecimal delta = ds.subtract(bv);
+            if (delta.signum() <= 0) {
+                return false;
+            }
+            int cmp = deltav.compareTo(delta);
+            return cmp < 0 || cmp == 0 && (c & 0x1) == 0;
+        }
+
+        return true;
+    }
+
+    abstract BigDecimal toBigDecimal();
+
+    abstract boolean recovers(BigDecimal b);
+
+    abstract boolean recovers(String s);
+
+    abstract int maxExp();
+
+    abstract int minExp();
+
+    abstract int maxLen10();
+
+    abstract boolean isZero();
+
+    abstract boolean isInfinity();
+
+    abstract void invert();
+
+    abstract boolean isNegative();
+
+    abstract boolean isNaN();
+
+}

From mandy.chung at oracle.com  Wed Sep 26 17:43:05 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 26 Sep 2018 10:43:05 -0700
Subject: RFR: JDK-8211121: Remove
 sun.reflect.ReflectionFactory::newInstanceForSerialization
In-Reply-To: <527FB28A-E78C-45EC-99E7-6365668336B6@oracle.com>
References: <2088542B-2FAD-4E22-A477-3A389DD2B1DE@oracle.com>
 <0fb723e4-2ded-d888-b8cd-8a51f9b54a4f@oracle.com>
 <527FB28A-E78C-45EC-99E7-6365668336B6@oracle.com>
Message-ID: <63bae6f5-9efa-318a-2eb3-12693d03a1fc@oracle.com>



On 9/26/18 10:01 AM, Lance Andersen wrote:
>
>> On Sep 26, 2018, at 1:19 AM, mandy chung <mandy.chung at oracle.com 
>> <mailto:mandy.chung at oracle.com>> wrote:
>>
>> The imports statement of jdk.internal.misc.SharedSecrets and 
>> JavaSecurityAccess can be removed.
>
> Thank you Mandy, ?thought I clicked to remove unused imports in 
> netbeans but guess I did not. ?Here is the revised diff

The revised diff looks good.

thanks
Mandy


From enasser at in.ibm.com  Wed Sep 26 17:44:25 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Wed, 26 Sep 2018 17:44:25 +0000
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero
 from java.text.DecimalFormat.format()
In-Reply-To: <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
Message-ID: <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>

Hi Joe,

Thank you for your review comments. 

I agree with you that the specification says that "The floating-point 
operations of the Java Virtual Machine do not throw exceptions, trap, or 
otherwise signal the IEEE 754 exceptional conditions of invalid operation, 
division by zero, overflow, underflow, or inexact." as per the JVM 
specification 
https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1
.

I noticed that the SIGFPE is consumed and no exception is thrown when 
SIGFPE is enabled before create JVM. Hence, there is an inconsistency in 
the hotspot behavior when the SIGFPE is enabled before and after create 
JVM. If the trap is enabled before create JVM, it just catch the exception 
and continue where as if the trap is enabled after create JVM, then it 
result in the ArithmeticException. Hence, the JVM behavior needs to be 
fixed to make the behavior consistent. 

Still, I feel it makes more sense to check the sign bit to decide a number 
is negative or positive rather than divide-by-zro to make infinity and 
compare with zero. If you agree with my view, a separate bug can be opened 
to fix the JVM inconsistent behavior. Otherwise, we can change the 
component of this bug. Please comment.

Thank you, 
Nasser Ebrahim



From:   joe darcy <joe.darcy at oracle.com>
To:     Nasser Ebrahim <enasser at in.ibm.com>, core-libs-dev Libs 
<core-libs-dev at openjdk.java.net>
Date:   09/26/2018 10:29 PM
Subject:        Re: RFR: JDK-8211161: java.lang.ArithmeticException: 
divide by zero from java.text.DecimalFormat.format()



Hello,

It may be reasonable to replace a divide by zero with check for a 
floating-point -0.0 with a bit-level check, but the stated motivation is 
not reasonable.

The Java platform requires that floating-point divide by zero return an 
infinity (or NaN as the case may be) and it is *incorrect* and 
non-conformant to throw an ArithmeticException in that case. Such 
behavior violates the language the JVM specs.

Cheers,

-Joe


On 9/26/2018 9:33 AM, Nasser Ebrahim wrote:
> Hello,
>
> In java.text.DecimalFormat.format(), there is a validation to check
> whether a number is negative zero or not and for that divide by zero is
> used to check for negative infinity which caused the ArithmeticException
> when SIGFPE is enabled in the system. Andrew has opened a bug on my
> behalf. Thank you Andrew.
>
> The corresponding bug is 
https://bugs.openjdk.java.net/browse/JDK-8211161
.
>
> The webrev and stand alone test case is uploaded to
> 
http://cr.openjdk.java.net/~aleonard/8211161/
.
> The recreate step is documented in the bug description.
>
> I have tested the fix with the test cases of the following bugs and
> confirm that it is working.
> 
https://bugs.java.com/view_bug.do?bug_id=4106658

> 
https://bugs.java.com/view_bug.do?bug_id=4106667

> 
https://bugs.java.com/view_bug.do?bug_id=4147706

>
> I did not add any new jtreg test for the current issue as it is not
> functional. Hope that is fine.
>
> Kindly request you to review and comment.
>
> Thank you,
> Nasser Ebrahim
>







From joe.darcy at oracle.com  Wed Sep 26 18:14:12 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 26 Sep 2018 11:14:12 -0700
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero
 from java.text.DecimalFormat.format()
In-Reply-To: <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
 <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
Message-ID: <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>

Hi Nasser,


On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
> Hi Joe,
>
> Thank you for your review comments.
>
> I agree with you that the specification says that "The floating-point 
> operations of the Java Virtual Machine do not throw exceptions, trap, 
> or otherwise signal the IEEE 754 exceptional conditions of invalid 
> operation, division by zero, overflow, underflow, or inexact." as per 
> the JVM specification 
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1.
>
> I noticed that the SIGFPE is consumed and no exception is thrown when 
> SIGFPE is enabled before create JVM. Hence, there is an inconsistency 
> in the hotspot behavior when the SIGFPE is enabled before and after 
> create JVM. If the trap is enabled before create JVM, it just catch 
> the exception and continue where as if the trap is enabled after 
> create JVM, then it result in the ArithmeticException.Hence, the JVM 
> behavior needs to be fixed to make the behavior consistent.
>
> Still, I feel it makes more sense to check the sign bit to decide a 
> number is negative or positive rather than divide-by-zro to make 
> infinity and compare with zero. If you agree with my view, a separate 
> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we 
> can change the component of this bug. Please comment.

Here is my rephrasing of the situation:

If someone deliberately misconfigures a CPU such that its floating-point 
behavior does not conform to the JVM specification, Java library code 
throws unexpected exceptions.

In that case, it is not a bug in the library code, it is a problem 
stemming from the deliberate CPU misconfiguration.

One could make a case that the new code is better in some way, perhaps 
faster on some platforms, but it is functionally correct as is and 
should not be described otherwise. The i18n team can weigh in with their 
assessment of the proposed patch from a maintenance perspective.

The HotSpot team could evaluate if the VM implementation should be 
further hardened against hostile changes to the FPU control word(s), but 
I would be content if this issue were closed as not a bug.

Cheers,

-Joe

From igor.ignatyev at oracle.com  Wed Sep 26 18:16:34 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 26 Sep 2018 11:16:34 -0700
Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary
Message-ID: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8211171/webrev.00/index.html
> 182 lines changed: 0 ins; 152 del; 30 mod;

Hi all,

could you please review this small and straightforward patch which moves JarUtils from jdk testlibrary to the top-level testlibrary, removes JarUtils from jaxp testlibrary, and updates all the affected tests?

please note, there is another version of JarUtils in jdk.test.lib.util package, but these two versions have different signatures and behavior, merging them is a bit tricker and will be done separately. 

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

Thanks,
-- Igor

From brian.burkhalter at oracle.com  Wed Sep 26 18:24:27 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Sep 2018 11:24:27 -0700
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
Message-ID: <AEEF4C78-E288-47B8-B26F-BCB6BA8E24D9@oracle.com>

Hi Raffaello,

Here is the webrev version of the patch:

http://cr.openjdk.java.net/~bpb/4511638/webrev.00/

On Sep 26, 2018, at 10:39 AM, raffaello.giulietti at gmail.com wrote:

> To address and overcome both issues, a new specification in the form of
> Javadoc associated to Double.toString(double) and Float.toString(float)
> is proposed, along with a clean-room re-implementation.

Thank you for the contribution.

> The intent of the specification is to explicitly separate the
> determination of the unique decimal number to represent the floating
> point argument (double/float) from its formatting as a String.
> 
> The clean-room implementation enjoys the following properties:
> * [?]
> * The new Double.toString(double) speedup with respect to the current
> implementation, according to jmh, is better than 13x when measured over
> bitwise uniformly distributed random samples.

I have corroborated this performance improvement on my MacBook Pro.

> * In the case of Double.toString(double), as it is infeasible to test
> all results, several billions of random doubles have been extensively
> tested.

I likewise ran a ?round trip? test similar to

Random.nextLong() -> Double.longBitsToDouble -> d0
d0 -> Double.toString -> Double.valueOf -> d1
Compare d0 vs. d1

which ran for 40 hours (366 billion round trips) on my MacBook Pro without error.

> Since there's a change in the specification, according to my sponsor and
> the formalities it has to undergo a CSR.

I will update the CSR.

> The submitted code contains both the changes to the current
> implementation and extensive jtreg tests.
> 
> While I've struggled to keep the code within the 80 chars/line limit,
> mercurial still generates longer lines. Thus, to avoid possible problems
> with the email systems, the code is submitted both inline and as an
> attachment. Hope at least one copy makes its way without errors.

Sounds good.

Thanks,

Brian

From aph at redhat.com  Wed Sep 26 18:53:48 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 26 Sep 2018 19:53:48 +0100
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
Message-ID: <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>

On 09/26/2018 06:07 PM, Ichiroh Takiguchi wrote:
> Sorry for bad operation.
> In case of s390x platform, this issue was fixed by JDK-8209637.
> https://bugs.openjdk.java.net/browse/JDK-8209637
> 
> If you could recreate this issue, please check JVM side also.

That does not fix the bug, except by accident. The native code should
be fixed too.

See the explanation in
https://bugs.openjdk.java.net/browse/JDK-8211163

-- 
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 martinrb at google.com  Wed Sep 26 18:53:48 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Sep 2018 11:53:48 -0700
Subject: RFR: jsr166 integration 2018-09
Message-ID: <CA+kOe09LJ9hZ1v50q3bfLeymhSsXgY6j8FMT9RJnGYbkLd-otA@mail.gmail.com>

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html

8210971: Add exception handling methods to CompletionStage and CompletableFuture
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/exceptionally/index.html
https://bugs.openjdk.java.net/browse/JDK-8210971

8207003: Miscellaneous changes imported from jsr166 CVS 2018-09
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8207003

This one continues to be stuck in CSR limbo:

8203662: remove increment of modCount from ArrayList and Vector replaceAll()
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html
https://bugs.openjdk.java.net/browse/JDK-8203662

From brian.burkhalter at oracle.com  Wed Sep 26 19:18:40 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Sep 2018 12:18:40 -0700
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <AEEF4C78-E288-47B8-B26F-BCB6BA8E24D9@oracle.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <AEEF4C78-E288-47B8-B26F-BCB6BA8E24D9@oracle.com>
Message-ID: <56360329-70C3-48BF-9A8B-7C63C3F2D3F4@oracle.com>

On Sep 26, 2018, at 11:24 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

>> Since there's a change in the specification, according to my sponsor and
>> the formalities it has to undergo a CSR.
> 
> I will update the CSR.

I updated the CSR [1] with the new verbiage for Double.toString() and Float.toString() and attached a specdiff versus the current JDK 12 repository. Please let me know of any errors.

Thanks,

Brian

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

From Alan.Bateman at oracle.com  Wed Sep 26 20:11:48 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Sep 2018 21:11:48 +0100
Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary
In-Reply-To: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>
References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>
Message-ID: <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com>



On 26/09/2018 19:16, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.00/index.html
Looks good but maybe it should be put into a named package (see below).

> :
> please note, there is another version of JarUtils in jdk.test.lib.util package, but these two versions have different signatures and behavior, merging them is a bit tricker and will be done separately.
>
The JarUtils that are moving today to test/lib is one that I added as 
test infrastructure some time ago. I don't where 
test/lib/jdk/test/lib/util/JarUtils.jav came from but it seems less 
useful. It makes me wonder if it would be better to just convert tests 
rather than merging. A few convenience methods added to the JarUtils you 
are moving would make that easier.

-Alan

From naoto.sato at oracle.com  Wed Sep 26 20:27:06 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 26 Sep 2018 13:27:06 -0700
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero
 from java.text.DecimalFormat.format()
In-Reply-To: <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
 <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
 <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
Message-ID: <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>

Hi, Nasser, Joe,

I agree with Joe as to the assessment on DecimalFormat code. The 
existing code looks correct. Unless there is any obvious need to replace 
the piece with bit operation, I'd just leave it as is. The jira issue 
can be transferred to HotSpot, though.

Naoto

On 9/26/18 11:14 AM, joe darcy wrote:
> Hi Nasser,
> 
> 
> On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
>> Hi Joe,
>>
>> Thank you for your review comments.
>>
>> I agree with you that the specification says that "The floating-point 
>> operations of the Java Virtual Machine do not throw exceptions, trap, 
>> or otherwise signal the IEEE 754 exceptional conditions of invalid 
>> operation, division by zero, overflow, underflow, or inexact." as per 
>> the JVM specification 
>> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1. 
>>
>>
>> I noticed that the SIGFPE is consumed and no exception is thrown when 
>> SIGFPE is enabled before create JVM. Hence, there is an inconsistency 
>> in the hotspot behavior when the SIGFPE is enabled before and after 
>> create JVM. If the trap is enabled before create JVM, it just catch 
>> the exception and continue where as if the trap is enabled after 
>> create JVM, then it result in the ArithmeticException.Hence, the JVM 
>> behavior needs to be fixed to make the behavior consistent.
>>
>> Still, I feel it makes more sense to check the sign bit to decide a 
>> number is negative or positive rather than divide-by-zro to make 
>> infinity and compare with zero. If you agree with my view, a separate 
>> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we 
>> can change the component of this bug. Please comment.
> 
> Here is my rephrasing of the situation:
> 
> If someone deliberately misconfigures a CPU such that its floating-point 
> behavior does not conform to the JVM specification, Java library code 
> throws unexpected exceptions.
> 
> In that case, it is not a bug in the library code, it is a problem 
> stemming from the deliberate CPU misconfiguration.
> 
> One could make a case that the new code is better in some way, perhaps 
> faster on some platforms, but it is functionally correct as is and 
> should not be described otherwise. The i18n team can weigh in with their 
> assessment of the proposed patch from a maintenance perspective.
> 
> The HotSpot team could evaluate if the VM implementation should be 
> further hardened against hostile changes to the FPU control word(s), but 
> I would be content if this issue were closed as not a bug.
> 
> Cheers,
> 
> -Joe

From Sergey.Bylokhov at oracle.com  Wed Sep 26 20:51:27 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Sep 2018 13:51:27 -0700
Subject: <Swing Dev> RFR; 8211031: Remove un-needed qualified export to
 java.desktop from java.base on macos
In-Reply-To: <5BA5D225.3040002@oracle.com>
References: <5BA550D7.6020104@oracle.com>
 <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>
 <5BA5D225.3040002@oracle.com>
Message-ID: <74630366-ddd2-503f-12f8-a3e3c8ecd037@oracle.com>

Hi, Phil.
On 21/09/2018 22:24, Philip Race wrote:
> [*] at this exact moment, cr.openjdk.java.net isn't working but hopefully
> that will be fixed by the time anyone reads this :-)

The classExists() method still there in version .1


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Sep 26 21:07:55 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 26 Sep 2018 14:07:55 -0700
Subject: <Swing Dev> RFR; 8211031: Remove un-needed qualified export to
 java.desktop from java.base on macos
In-Reply-To: <74630366-ddd2-503f-12f8-a3e3c8ecd037@oracle.com>
References: <5BA550D7.6020104@oracle.com>
 <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>
 <5BA5D225.3040002@oracle.com>
 <74630366-ddd2-503f-12f8-a3e3c8ecd037@oracle.com>
Message-ID: <5b2bde90-ca79-7496-4b1a-af2065066393@oracle.com>

Not 100% sure what happened there. I've re-uploaded it.
Shift-reload to avoid browser caching and look again.

-phil.

On 09/26/2018 01:51 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> On 21/09/2018 22:24, Philip Race wrote:
>> [*] at this exact moment, cr.openjdk.java.net isn't working but 
>> hopefully
>> that will be fixed by the time anyone reads this :-)
>
> The classExists() method still there in version .1
>
>


From igor.ignatyev at oracle.com  Wed Sep 26 21:25:24 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 26 Sep 2018 14:25:24 -0700
Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary
In-Reply-To: <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com>
References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>
 <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com>
Message-ID: <EC7A8505-C791-4175-8EF2-04A0521A8CE1@oracle.com>

Hi Alan,

it appears that I have to put into a named package as the jaxp test which uses it is in a named package.

although I don't want to group simple moving and more sophisticated test conversion for the sake of reviewers, also there is another "duplicate" of JarUtils in test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java. I'd prefer to "merge" all three instances together, where merge might be implemented as conversion of tests.

so as an intermediate step, I propose to move all the methods of JarUtils into jdk.test.lib.util.JarUtils.

Thanks,
-- Igor
> On Sep 26, 2018, at 1:11 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 26/09/2018 19:16, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.00/index.html
> Looks good but maybe it should be put into a named package (see below).
> 
>> :
>> please note, there is another version of JarUtils in jdk.test.lib.util package, but these two versions have different signatures and behavior, merging them is a bit tricker and will be done separately.
>> 
> The JarUtils that are moving today to test/lib is one that I added as test infrastructure some time ago. I don't where test/lib/jdk/test/lib/util/JarUtils.jav came from but it seems less useful. It makes me wonder if it would be better to just convert tests rather than merging. A few convenience methods added to the JarUtils you are moving would make that easier.
> 
> -Alan


From zhangbodut at gmail.com  Wed Sep 26 23:03:44 2018
From: zhangbodut at gmail.com (Bo Zhang)
Date: Thu, 27 Sep 2018 07:03:44 +0800
Subject: [PATCH] 8210810: Incorrect argument file parser behavior in
 certain cases
In-Reply-To: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
Message-ID: <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>

Can anyone please take a look?

Thank you.

> On 25 Sep 2018, at 14:27, Bo Zhang <zhangbodut at gmail.com> wrote:
> 
> Hi all,
> 
> This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed the OCA with the name ?Bo Zhang?.
> 
> Bug description:
> 
> 8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>: Incorrect argument file parser behavior in certain cases
> 
> Previously, if a quoted backslash character appears at argument file
> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
> file is backslash '\'), the segment before the backslash character will
> be added into argument twice due to a missing anchor position reset
> operation.
> 
> For example, you have an argument file:
> 
> -cp "...a\\b"
> 
> and the 4096th and 4097th characters happen to be both '\', the result
> generated by the argument file parser would be:
> 
> -cp "...aa\\b?
> 
> This patch fixes the issue by resetting anchor position correctly
> in this case.
> 
> I?m a little surprised that this issue has existed for several years unnoticed.
> 
> 
> Patch:
> 
> # HG changeset patch
> # User Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>>
> # Date 1537835887 -28800
> #      Tue Sep 25 08:38:07 2018 +0800
> # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352
> # Parent  16f0deae8fa6ef85f7230308e1fe7556bd007c39
> 8210810: Incorrect argument file parser behavior in certain cases
> 
> Previously, if a quoted backslash character appears at argument file
> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
> file is backslash '\'), the segment before the backslash character will
> be added into argument twice due to a missing anchor position reset
> operation.
> 
> For example, you have an argument file:
> 
> -cp "...a\\b"
> 
> and the 4096th and 4097th characters happen to be both '\', the result
> generated by the argument file parser would be:
> 
> -cp "...aa\\b"
> 
> This patch fixes the issue by resetting anchor position correctly
> in this case.
> 
> diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c
> --- a/src/java.base/share/native/libjli/args.c
> +++ b/src/java.base/share/native/libjli/args.c
> @@ -262,6 +262,8 @@
>                      continue;
>                  }
>                  JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor);
> +                // anchor after backslash character
> +                anchor = nextc + 1;
>                  pctx->state = IN_ESCAPE;
>                  break;
>              case '\'':
> diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java
> new file mode 100644
> --- /dev/null
> +++ b/test/jdk/tools/launcher/Test8210810.java
> @@ -0,0 +1,107 @@
> +/*
> + * Copyright (c) 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
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com <http://www.oracle.com/> if you need additional information or have any
> + * questions.
> + */
> +
> +/*
> + * @test
> + * @bug 8210810
> + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary
> + * @modules java.base
> + * @author Bo Zhang
> + * @build TestHelper
> + * @run main Test8210810
> + */
> +
> +/*
> + * 8210810: Previously, if a quoted backslash character appears at argument file
> + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
> + * file is backslash '\'), the segment before the backslash character will
> + * be added into argument twice due to a missing anchor position reset
> + * operation. This test creates a special argument file which can reproduce this issue.
> + */
> +import java.io.File;
> +import java.nio.file.Files;
> +import java.io.IOException;
> +import java.util.Arrays;
> +
> +public class Test8210810 extends TestHelper {
> +    // Buffer size in args.c readArgFile() method
> +    private static final int ARG_FILE_PARSER_BUF_SIZE = 4096;
> +    public static void main(String... args) throws Exception {
> +        new Test8210810().canParseArgFileCorrectly();
> +    }
> +
> +    private void canParseArgFileCorrectly() throws IOException {
> +        File testJar = createTestClassWhichPrintsClasspath();
> +        File argFile = createArgFileWithSpecificClasspath();
> +        TestResult result = doExec(javaCmd, "@argFile", "Foo");
> +
> +        long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath())));
> +        long zCountReadByParser = countZ(result.testOutput.get(0));
> +        if(zCountInArgFile != zCountReadByParser) {
> +            throw new RuntimeException("Classpath parsed by parser is different from argument file!");
> +        }
> +
> +        testJar.delete();
> +        argFile.delete();
> +    }
> +
> +    private long countZ(String str) {
> +        return str.chars().filter(ch -> ch == 'z').count();
> +    }
> +
> +    private File createTestClassWhichPrintsClasspath() throws IOException {
> +        File testJar = new File("test.jar");
> +        testJar.delete();
> +
> +        StringBuilder tsrc = new StringBuilder();
> +        tsrc.append("public static void main(String... args) {\n");
> +        tsrc.append("   System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n");
> +        tsrc.append("}\n");
> +        createJar(testJar, new File("Foo"), tsrc.toString());
> +        return testJar;
> +    }
> +
> +    // Create a file whose 4096th and 4097th characters are both '\' (backslash)
> +    // File content:
> +    // |-cp "test.jar:zzzzz...zzz\\"|
> +    private File createArgFileWithSpecificClasspath() throws IOException {
> +        File argFile = new File("argFile");
> +        argFile.delete();
> +
> +        StringBuilder arg = new StringBuilder("-cp \"test.jar");
> +        arg.append(File.pathSeparator);
> +
> +        int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length();
> +
> +        for(int i = 0; i < fillingCharactersCount; ++i) {
> +            arg.append('z');
> +        }
> +
> +        arg.append('\\'); // 4096th character in the arg file
> +        arg.append('\\'); // 4097th character in the arg file
> +        arg.append('"');
> +
> +        createAFile(argFile, Arrays.asList(arg.toString()));
> +        return argFile;
> +    }
> +}
> 
> Unit test:
> 
> Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical.
> 
> <8210810.patch>
> 


From stuart.marks at oracle.com  Wed Sep 26 23:08:09 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 26 Sep 2018 16:08:09 -0700
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <ceb5be7d-b8a5-cf94-be59-f5d8a7947cdb@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
 <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
 <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>
 <3d2763a8-fac9-69ad-7d2e-03184deb4138@gmail.com>
 <ceb5be7d-b8a5-cf94-be59-f5d8a7947cdb@oracle.com>
Message-ID: <19af220e-d96f-6080-94e1-5119d36b4a93@oracle.com>

Hi, I just wanted to mention that I pushed the changeset for this bug:

     http://hg.openjdk.java.net/jdk/jdk/rev/2ee7e1b7ba66

Thanks for your contribution to OpenJDK!

s'marks

From igor.ignatyev at oracle.com  Wed Sep 26 23:38:39 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 26 Sep 2018 16:38:39 -0700
Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary
In-Reply-To: <EC7A8505-C791-4175-8EF2-04A0521A8CE1@oracle.com>
References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>
 <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com>
 <EC7A8505-C791-4175-8EF2-04A0521A8CE1@oracle.com>
Message-ID: <A4D7C24D-98FF-474C-AD4A-46495CCDD815@oracle.com>

here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils:
whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html <http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html>
> 655 lines changed: 239 ins; 355 del; 61 mod;
incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html <http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html>
> 476 lines changed: 239 ins; 203 del; 34 mod;

doing that, I noticed that both updateJarFile and createJarFile don't close Stream<Path> from Files::find, the current patch fixes that.

-- Igor

> On Sep 26, 2018, at 2:25 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Hi Alan,
> 
> it appears that I have to put into a named package as the jaxp test which uses it is in a named package.
> 
> although I don't want to group simple moving and more sophisticated test conversion for the sake of reviewers, also there is another "duplicate" of JarUtils in test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java. I'd prefer to "merge" all three instances together, where merge might be implemented as conversion of tests.
> 
> so as an intermediate step, I propose to move all the methods of JarUtils into jdk.test.lib.util.JarUtils.
> 
> Thanks,
> -- Igor
>> On Sep 26, 2018, at 1:11 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 
>> 
>> On 26/09/2018 19:16, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.00/index.html
>> Looks good but maybe it should be put into a named package (see below).
>> 
>>> :
>>> please note, there is another version of JarUtils in jdk.test.lib.util package, but these two versions have different signatures and behavior, merging them is a bit tricker and will be done separately.
>>> 
>> The JarUtils that are moving today to test/lib is one that I added as test infrastructure some time ago. I don't where test/lib/jdk/test/lib/util/JarUtils.jav came from but it seems less useful. It makes me wonder if it would be better to just convert tests rather than merging. A few convenience methods added to the JarUtils you are moving would make that easier.
>> 
>> -Alan
> 


From brian.burkhalter at oracle.com  Wed Sep 26 23:53:31 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Sep 2018 16:53:31 -0700
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <56360329-70C3-48BF-9A8B-7C63C3F2D3F4@oracle.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <AEEF4C78-E288-47B8-B26F-BCB6BA8E24D9@oracle.com>
 <56360329-70C3-48BF-9A8B-7C63C3F2D3F4@oracle.com>
Message-ID: <2E379E99-31FC-4902-9359-B79E3B0D8078@oracle.com>

There was a compilation error on Linux in one of the tests:

test/jdk/java/lang/Floating/DoubleToDecString.java:133: error: unmappable character (0x93) for encoding US-ASCII
    Paxson V, "A Program for Testing IEEE Decimal\ufffd\ufffd\ufffdBinary Conversion"

This was only in one of the comments where it looks like some errant character leaked in. I updated the webrev (with accompanying patch) in place [1] after verifying that the change to the test fixes the problem. 

Also, there were a couple of failures observed in test [2] at lines 172 and 173. If at line 172 "foo1.17549435E-38? is changed to "foo1.1754944E-38? then the evaluation at that line succeeds but then the one at line 173 fails. Making a similar change on this line does not help. I suspect that this is due to a difference between the new code and that in jdk.internal.math.FloatingDecimal which is used by java.lang.AbstractStringBuilder and java.lang.invoke.StringConcatFactory but I?ve not actually investigated this as yet. I had actually wondered whether some or all of the FloatingDecimal code could be superseded by the updated logic.

Brian

[1] http://cr.openjdk.java.net/~bpb/4511638/webrev.00/
[2] java/lang/String/concat/ImplicitStringConcatBoundaries.java

From henry.jen at oracle.com  Thu Sep 27 01:39:54 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 26 Sep 2018 18:39:54 -0700
Subject: [PATCH] 8210810: Incorrect argument file parser behavior in
 certain cases
In-Reply-To: <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
Message-ID: <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>

Thanks for the fix. I had looked into it, it?s a nice catch, glad you find it.

The patch looks good, and test is sufficient, I have tested it with jdk.jdk repo. I will help you to push the fix. The only minor improvement I like to see is to verify content after the escape character, which I took the liberty to do it. Webrev coming soon.

Cheers,
Henry

> On Sep 26, 2018, at 4:03 PM, Bo Zhang <zhangbodut at gmail.com> wrote:
> 
> Can anyone please take a look?
> 
> Thank you.
> 
>> On 25 Sep 2018, at 14:27, Bo Zhang <zhangbodut at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed the OCA with the name ?Bo Zhang?.
>> 
>> Bug description:
>> 
>> 8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>: Incorrect argument file parser behavior in certain cases
>> 
>> Previously, if a quoted backslash character appears at argument file
>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>> file is backslash '\'), the segment before the backslash character will
>> be added into argument twice due to a missing anchor position reset
>> operation.
>> 
>> For example, you have an argument file:
>> 
>> -cp "...a\\b"
>> 
>> and the 4096th and 4097th characters happen to be both '\', the result
>> generated by the argument file parser would be:
>> 
>> -cp "...aa\\b?
>> 
>> This patch fixes the issue by resetting anchor position correctly
>> in this case.
>> 
>> I?m a little surprised that this issue has existed for several years unnoticed.
>> 
>> 
>> Patch:
>> 
>> # HG changeset patch
>> # User Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>>
>> # Date 1537835887 -28800
>> #      Tue Sep 25 08:38:07 2018 +0800
>> # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352
>> # Parent  16f0deae8fa6ef85f7230308e1fe7556bd007c39
>> 8210810: Incorrect argument file parser behavior in certain cases
>> 
>> Previously, if a quoted backslash character appears at argument file
>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>> file is backslash '\'), the segment before the backslash character will
>> be added into argument twice due to a missing anchor position reset
>> operation.
>> 
>> For example, you have an argument file:
>> 
>> -cp "...a\\b"
>> 
>> and the 4096th and 4097th characters happen to be both '\', the result
>> generated by the argument file parser would be:
>> 
>> -cp "...aa\\b"
>> 
>> This patch fixes the issue by resetting anchor position correctly
>> in this case.
>> 
>> diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c
>> --- a/src/java.base/share/native/libjli/args.c
>> +++ b/src/java.base/share/native/libjli/args.c
>> @@ -262,6 +262,8 @@
>>                     continue;
>>                 }
>>                 JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor);
>> +                // anchor after backslash character
>> +                anchor = nextc + 1;
>>                 pctx->state = IN_ESCAPE;
>>                 break;
>>             case '\'':
>> diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java
>> new file mode 100644
>> --- /dev/null
>> +++ b/test/jdk/tools/launcher/Test8210810.java
>> @@ -0,0 +1,107 @@
>> +/*
>> + * Copyright (c) 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
>> + * under the terms of the GNU General Public License version 2 only, as
>> + * published by the Free Software Foundation.
>> + *
>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> + * version 2 for more details (a copy is included in the LICENSE file that
>> + * accompanied this code).
>> + *
>> + * You should have received a copy of the GNU General Public License version
>> + * 2 along with this work; if not, write to the Free Software Foundation,
>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> + *
>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>> + * or visit www.oracle.com <http://www.oracle.com/> if you need additional information or have any
>> + * questions.
>> + */
>> +
>> +/*
>> + * @test
>> + * @bug 8210810
>> + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary
>> + * @modules java.base
>> + * @author Bo Zhang
>> + * @build TestHelper
>> + * @run main Test8210810
>> + */
>> +
>> +/*
>> + * 8210810: Previously, if a quoted backslash character appears at argument file
>> + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>> + * file is backslash '\'), the segment before the backslash character will
>> + * be added into argument twice due to a missing anchor position reset
>> + * operation. This test creates a special argument file which can reproduce this issue.
>> + */
>> +import java.io.File;
>> +import java.nio.file.Files;
>> +import java.io.IOException;
>> +import java.util.Arrays;
>> +
>> +public class Test8210810 extends TestHelper {
>> +    // Buffer size in args.c readArgFile() method
>> +    private static final int ARG_FILE_PARSER_BUF_SIZE = 4096;
>> +    public static void main(String... args) throws Exception {
>> +        new Test8210810().canParseArgFileCorrectly();
>> +    }
>> +
>> +    private void canParseArgFileCorrectly() throws IOException {
>> +        File testJar = createTestClassWhichPrintsClasspath();
>> +        File argFile = createArgFileWithSpecificClasspath();
>> +        TestResult result = doExec(javaCmd, "@argFile", "Foo");
>> +
>> +        long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath())));
>> +        long zCountReadByParser = countZ(result.testOutput.get(0));
>> +        if(zCountInArgFile != zCountReadByParser) {
>> +            throw new RuntimeException("Classpath parsed by parser is different from argument file!");
>> +        }
>> +
>> +        testJar.delete();
>> +        argFile.delete();
>> +    }
>> +
>> +    private long countZ(String str) {
>> +        return str.chars().filter(ch -> ch == 'z').count();
>> +    }
>> +
>> +    private File createTestClassWhichPrintsClasspath() throws IOException {
>> +        File testJar = new File("test.jar");
>> +        testJar.delete();
>> +
>> +        StringBuilder tsrc = new StringBuilder();
>> +        tsrc.append("public static void main(String... args) {\n");
>> +        tsrc.append("   System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n");
>> +        tsrc.append("}\n");
>> +        createJar(testJar, new File("Foo"), tsrc.toString());
>> +        return testJar;
>> +    }
>> +
>> +    // Create a file whose 4096th and 4097th characters are both '\' (backslash)
>> +    // File content:
>> +    // |-cp "test.jar:zzzzz...zzz\\"|
>> +    private File createArgFileWithSpecificClasspath() throws IOException {
>> +        File argFile = new File("argFile");
>> +        argFile.delete();
>> +
>> +        StringBuilder arg = new StringBuilder("-cp \"test.jar");
>> +        arg.append(File.pathSeparator);
>> +
>> +        int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length();
>> +
>> +        for(int i = 0; i < fillingCharactersCount; ++i) {
>> +            arg.append('z');
>> +        }
>> +
>> +        arg.append('\\'); // 4096th character in the arg file
>> +        arg.append('\\'); // 4097th character in the arg file
>> +        arg.append('"');
>> +
>> +        createAFile(argFile, Arrays.asList(arg.toString()));
>> +        return argFile;
>> +    }
>> +}
>> 
>> Unit test:
>> 
>> Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical.
>> 
>> <8210810.patch>
>> 
> 


From zhangbodut at gmail.com  Thu Sep 27 01:45:02 2018
From: zhangbodut at gmail.com (Bo Zhang)
Date: Thu, 27 Sep 2018 09:45:02 +0800
Subject: [PATCH] 8210810: Incorrect argument file parser behavior in
 certain cases
In-Reply-To: <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
Message-ID: <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>

Thank you Henry. Feel free to modify it.

Regards,
Bo

> On 27 Sep 2018, at 09:39, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Thanks for the fix. I had looked into it, it?s a nice catch, glad you find it.
> 
> The patch looks good, and test is sufficient, I have tested it with jdk.jdk repo. I will help you to push the fix. The only minor improvement I like to see is to verify content after the escape character, which I took the liberty to do it. Webrev coming soon.
> 
> Cheers,
> Henry
> 
>> On Sep 26, 2018, at 4:03 PM, Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>> wrote:
>> 
>> Can anyone please take a look?
>> 
>> Thank you.
>> 
>>> On 25 Sep 2018, at 14:27, Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed the OCA with the name ?Bo Zhang?.
>>> 
>>> Bug description:
>>> 
>>> 8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>>: Incorrect argument file parser behavior in certain cases
>>> 
>>> Previously, if a quoted backslash character appears at argument file
>>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>> file is backslash '\'), the segment before the backslash character will
>>> be added into argument twice due to a missing anchor position reset
>>> operation.
>>> 
>>> For example, you have an argument file:
>>> 
>>> -cp "...a\\b"
>>> 
>>> and the 4096th and 4097th characters happen to be both '\', the result
>>> generated by the argument file parser would be:
>>> 
>>> -cp "...aa\\b?
>>> 
>>> This patch fixes the issue by resetting anchor position correctly
>>> in this case.
>>> 
>>> I?m a little surprised that this issue has existed for several years unnoticed.
>>> 
>>> 
>>> Patch:
>>> 
>>> # HG changeset patch
>>> # User Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com> <mailto:zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>>>
>>> # Date 1537835887 -28800
>>> #      Tue Sep 25 08:38:07 2018 +0800
>>> # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352
>>> # Parent  16f0deae8fa6ef85f7230308e1fe7556bd007c39
>>> 8210810: Incorrect argument file parser behavior in certain cases
>>> 
>>> Previously, if a quoted backslash character appears at argument file
>>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>> file is backslash '\'), the segment before the backslash character will
>>> be added into argument twice due to a missing anchor position reset
>>> operation.
>>> 
>>> For example, you have an argument file:
>>> 
>>> -cp "...a\\b"
>>> 
>>> and the 4096th and 4097th characters happen to be both '\', the result
>>> generated by the argument file parser would be:
>>> 
>>> -cp "...aa\\b"
>>> 
>>> This patch fixes the issue by resetting anchor position correctly
>>> in this case.
>>> 
>>> diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c
>>> --- a/src/java.base/share/native/libjli/args.c
>>> +++ b/src/java.base/share/native/libjli/args.c
>>> @@ -262,6 +262,8 @@
>>>                    continue;
>>>                }
>>>                JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor);
>>> +                // anchor after backslash character
>>> +                anchor = nextc + 1;
>>>                pctx->state = IN_ESCAPE;
>>>                break;
>>>            case '\'':
>>> diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java
>>> new file mode 100644
>>> --- /dev/null
>>> +++ b/test/jdk/tools/launcher/Test8210810.java
>>> @@ -0,0 +1,107 @@
>>> +/*
>>> + * Copyright (c) 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
>>> + * under the terms of the GNU General Public License version 2 only, as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>> + * version 2 for more details (a copy is included in the LICENSE file that
>>> + * accompanied this code).
>>> + *
>>> + * You should have received a copy of the GNU General Public License version
>>> + * 2 along with this work; if not, write to the Free Software Foundation,
>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>> + *
>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>> + * or visit www.oracle.com <http://www.oracle.com/> <http://www.oracle.com/ <http://www.oracle.com/>> if you need additional information or have any
>>> + * questions.
>>> + */
>>> +
>>> +/*
>>> + * @test
>>> + * @bug 8210810
>>> + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary
>>> + * @modules java.base
>>> + * @author Bo Zhang
>>> + * @build TestHelper
>>> + * @run main Test8210810
>>> + */
>>> +
>>> +/*
>>> + * 8210810: Previously, if a quoted backslash character appears at argument file
>>> + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>> + * file is backslash '\'), the segment before the backslash character will
>>> + * be added into argument twice due to a missing anchor position reset
>>> + * operation. This test creates a special argument file which can reproduce this issue.
>>> + */
>>> +import java.io.File;
>>> +import java.nio.file.Files;
>>> +import java.io.IOException;
>>> +import java.util.Arrays;
>>> +
>>> +public class Test8210810 extends TestHelper {
>>> +    // Buffer size in args.c readArgFile() method
>>> +    private static final int ARG_FILE_PARSER_BUF_SIZE = 4096;
>>> +    public static void main(String... args) throws Exception {
>>> +        new Test8210810().canParseArgFileCorrectly();
>>> +    }
>>> +
>>> +    private void canParseArgFileCorrectly() throws IOException {
>>> +        File testJar = createTestClassWhichPrintsClasspath();
>>> +        File argFile = createArgFileWithSpecificClasspath();
>>> +        TestResult result = doExec(javaCmd, "@argFile", "Foo");
>>> +
>>> +        long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath())));
>>> +        long zCountReadByParser = countZ(result.testOutput.get(0));
>>> +        if(zCountInArgFile != zCountReadByParser) {
>>> +            throw new RuntimeException("Classpath parsed by parser is different from argument file!");
>>> +        }
>>> +
>>> +        testJar.delete();
>>> +        argFile.delete();
>>> +    }
>>> +
>>> +    private long countZ(String str) {
>>> +        return str.chars().filter(ch -> ch == 'z').count();
>>> +    }
>>> +
>>> +    private File createTestClassWhichPrintsClasspath() throws IOException {
>>> +        File testJar = new File("test.jar");
>>> +        testJar.delete();
>>> +
>>> +        StringBuilder tsrc = new StringBuilder();
>>> +        tsrc.append("public static void main(String... args) {\n");
>>> +        tsrc.append("   System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n");
>>> +        tsrc.append("}\n");
>>> +        createJar(testJar, new File("Foo"), tsrc.toString());
>>> +        return testJar;
>>> +    }
>>> +
>>> +    // Create a file whose 4096th and 4097th characters are both '\' (backslash)
>>> +    // File content:
>>> +    // |-cp "test.jar:zzzzz...zzz\\"|
>>> +    private File createArgFileWithSpecificClasspath() throws IOException {
>>> +        File argFile = new File("argFile");
>>> +        argFile.delete();
>>> +
>>> +        StringBuilder arg = new StringBuilder("-cp \"test.jar");
>>> +        arg.append(File.pathSeparator);
>>> +
>>> +        int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length();
>>> +
>>> +        for(int i = 0; i < fillingCharactersCount; ++i) {
>>> +            arg.append('z');
>>> +        }
>>> +
>>> +        arg.append('\\'); // 4096th character in the arg file
>>> +        arg.append('\\'); // 4097th character in the arg file
>>> +        arg.append('"');
>>> +
>>> +        createAFile(argFile, Arrays.asList(arg.toString()));
>>> +        return argFile;
>>> +    }
>>> +}
>>> 
>>> Unit test:
>>> 
>>> Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical.
>>> 
>>> <8210810.patch>


From takiguc at linux.vnet.ibm.com  Thu Sep 27 02:32:21 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 27 Sep 2018 11:32:21 +0900
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
 <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
Message-ID: <366b37f3da706619ea4351016c3af5ec@linux.vnet.ibm.com>

Hello Andrew.

FYI, about jboolean value discussion was started following mail
  * Is returning a value != '0' or '1' as jboolean from a JNI function 
legal?
  
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054906.html

Anyway, it's better to fix this issue.

On 2018-09-27 03:53, Andrew Haley wrote:
> On 09/26/2018 06:07 PM, Ichiroh Takiguchi wrote:
>> Sorry for bad operation.
>> In case of s390x platform, this issue was fixed by JDK-8209637.
>> https://bugs.openjdk.java.net/browse/JDK-8209637
>> 
>> If you could recreate this issue, please check JVM side also.
> 
> That does not fix the bug, except by accident. The native code should
> be fixed too.
> 
> See the explanation in
> https://bugs.openjdk.java.net/browse/JDK-8211163


From henry.jen at oracle.com  Thu Sep 27 02:58:05 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 26 Sep 2018 19:58:05 -0700
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
Message-ID: <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>

Hi,

Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.

I had reviewed the change and tested, but we need a ?R?eviewer.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8210810

> On Sep 26, 2018, at 6:45 PM, Bo Zhang <zhangbodut at gmail.com> wrote:
> 
> Thank you Henry. Feel free to modify it.
> 
> Regards,
> Bo
> 
>> On 27 Sep 2018, at 09:39, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> Thanks for the fix. I had looked into it, it?s a nice catch, glad you find it.
>> 
>> The patch looks good, and test is sufficient, I have tested it with jdk.jdk repo. I will help you to push the fix. The only minor improvement I like to see is to verify content after the escape character, which I took the liberty to do it. Webrev coming soon.
>> 
>> Cheers,
>> Henry
>> 
>>> On Sep 26, 2018, at 4:03 PM, Bo Zhang <zhangbodut at gmail.com> wrote:
>>> 
>>> Can anyone please take a look?
>>> 
>>> Thank you.
>>> 
>>>> On 25 Sep 2018, at 14:27, Bo Zhang <zhangbodut at gmail.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I?ve signed the OCA with the name ?Bo Zhang?.
>>>> 
>>>> Bug description:
>>>> 
>>>> 8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>: Incorrect argument file parser behavior in certain cases
>>>> 
>>>> Previously, if a quoted backslash character appears at argument file
>>>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>>> file is backslash '\'), the segment before the backslash character will
>>>> be added into argument twice due to a missing anchor position reset
>>>> operation.
>>>> 
>>>> For example, you have an argument file:
>>>> 
>>>> -cp "...a\\b"
>>>> 
>>>> and the 4096th and 4097th characters happen to be both '\', the result
>>>> generated by the argument file parser would be:
>>>> 
>>>> -cp "...aa\\b?
>>>> 
>>>> This patch fixes the issue by resetting anchor position correctly
>>>> in this case.
>>>> 
>>>> I?m a little surprised that this issue has existed for several years unnoticed.
>>>> 
>>>> 
>>>> Patch:
>>>> 
>>>> # HG changeset patch
>>>> # User Bo Zhang <zhangbodut at gmail.com <mailto:zhangbodut at gmail.com>>
>>>> # Date 1537835887 -28800
>>>> #      Tue Sep 25 08:38:07 2018 +0800
>>>> # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352
>>>> # Parent  16f0deae8fa6ef85f7230308e1fe7556bd007c39
>>>> 8210810: Incorrect argument file parser behavior in certain cases
>>>> 
>>>> Previously, if a quoted backslash character appears at argument file
>>>> parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>>> file is backslash '\'), the segment before the backslash character will
>>>> be added into argument twice due to a missing anchor position reset
>>>> operation.
>>>> 
>>>> For example, you have an argument file:
>>>> 
>>>> -cp "...a\\b"
>>>> 
>>>> and the 4096th and 4097th characters happen to be both '\', the result
>>>> generated by the argument file parser would be:
>>>> 
>>>> -cp "...aa\\b"
>>>> 
>>>> This patch fixes the issue by resetting anchor position correctly
>>>> in this case.
>>>> 
>>>> diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c
>>>> --- a/src/java.base/share/native/libjli/args.c
>>>> +++ b/src/java.base/share/native/libjli/args.c
>>>> @@ -262,6 +262,8 @@
>>>>                    continue;
>>>>                }
>>>>                JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor);
>>>> +                // anchor after backslash character
>>>> +                anchor = nextc + 1;
>>>>                pctx->state = IN_ESCAPE;
>>>>                break;
>>>>            case '\'':
>>>> diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java
>>>> new file mode 100644
>>>> --- /dev/null
>>>> +++ b/test/jdk/tools/launcher/Test8210810.java
>>>> @@ -0,0 +1,107 @@
>>>> +/*
>>>> + * Copyright (c) 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
>>>> + * under the terms of the GNU General Public License version 2 only, as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This code is distributed in the hope that it will be useful, but WITHOUT
>>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>>> + * version 2 for more details (a copy is included in the LICENSE file that
>>>> + * accompanied this code).
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License version
>>>> + * 2 along with this work; if not, write to the Free Software Foundation,
>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>> + *
>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>>> + * or visit www.oracle.com <http://www.oracle.com/> if you need additional information or have any
>>>> + * questions.
>>>> + */
>>>> +
>>>> +/*
>>>> + * @test
>>>> + * @bug 8210810
>>>> + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary
>>>> + * @modules java.base
>>>> + * @author Bo Zhang
>>>> + * @build TestHelper
>>>> + * @run main Test8210810
>>>> + */
>>>> +
>>>> +/*
>>>> + * 8210810: Previously, if a quoted backslash character appears at argument file
>>>> + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument
>>>> + * file is backslash '\'), the segment before the backslash character will
>>>> + * be added into argument twice due to a missing anchor position reset
>>>> + * operation. This test creates a special argument file which can reproduce this issue.
>>>> + */
>>>> +import java.io.File;
>>>> +import java.nio.file.Files;
>>>> +import java.io.IOException;
>>>> +import java.util.Arrays;
>>>> +
>>>> +public class Test8210810 extends TestHelper {
>>>> +    // Buffer size in args.c readArgFile() method
>>>> +    private static final int ARG_FILE_PARSER_BUF_SIZE = 4096;
>>>> +    public static void main(String... args) throws Exception {
>>>> +        new Test8210810().canParseArgFileCorrectly();
>>>> +    }
>>>> +
>>>> +    private void canParseArgFileCorrectly() throws IOException {
>>>> +        File testJar = createTestClassWhichPrintsClasspath();
>>>> +        File argFile = createArgFileWithSpecificClasspath();
>>>> +        TestResult result = doExec(javaCmd, "@argFile", "Foo");
>>>> +
>>>> +        long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath())));
>>>> +        long zCountReadByParser = countZ(result.testOutput.get(0));
>>>> +        if(zCountInArgFile != zCountReadByParser) {
>>>> +            throw new RuntimeException("Classpath parsed by parser is different from argument file!");
>>>> +        }
>>>> +
>>>> +        testJar.delete();
>>>> +        argFile.delete();
>>>> +    }
>>>> +
>>>> +    private long countZ(String str) {
>>>> +        return str.chars().filter(ch -> ch == 'z').count();
>>>> +    }
>>>> +
>>>> +    private File createTestClassWhichPrintsClasspath() throws IOException {
>>>> +        File testJar = new File("test.jar");
>>>> +        testJar.delete();
>>>> +
>>>> +        StringBuilder tsrc = new StringBuilder();
>>>> +        tsrc.append("public static void main(String... args) {\n");
>>>> +        tsrc.append("   System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n");
>>>> +        tsrc.append("}\n");
>>>> +        createJar(testJar, new File("Foo"), tsrc.toString());
>>>> +        return testJar;
>>>> +    }
>>>> +
>>>> +    // Create a file whose 4096th and 4097th characters are both '\' (backslash)
>>>> +    // File content:
>>>> +    // |-cp "test.jar:zzzzz...zzz\\"|
>>>> +    private File createArgFileWithSpecificClasspath() throws IOException {
>>>> +        File argFile = new File("argFile");
>>>> +        argFile.delete();
>>>> +
>>>> +        StringBuilder arg = new StringBuilder("-cp \"test.jar");
>>>> +        arg.append(File.pathSeparator);
>>>> +
>>>> +        int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length();
>>>> +
>>>> +        for(int i = 0; i < fillingCharactersCount; ++i) {
>>>> +            arg.append('z');
>>>> +        }
>>>> +
>>>> +        arg.append('\\'); // 4096th character in the arg file
>>>> +        arg.append('\\'); // 4097th character in the arg file
>>>> +        arg.append('"');
>>>> +
>>>> +        createAFile(argFile, Arrays.asList(arg.toString()));
>>>> +        return argFile;
>>>> +    }
>>>> +}
>>>> 
>>>> Unit test:
>>>> 
>>>> Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ?\?. Then it compares the classpath read in the VM and the classpath in the argument file to verify they?re identical.
>>>> 
>>>> <8210810.patch>
> 


From jai.forums2013 at gmail.com  Thu Sep 27 03:12:58 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 27 Sep 2018 08:42:58 +0530
Subject: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
In-Reply-To: <19af220e-d96f-6080-94e1-5119d36b4a93@oracle.com>
References: <761d3ff3-2fbf-1257-67af-2fcb3d45be3a@gmail.com>
 <563abe7e-b139-66a7-f27f-916f8410b6a7@gmail.com>
 <DB7PR08MB330785E38CF7E0E7AD343D6FFF090@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <eb678fed-9ee9-b7d5-3df8-03bc5974e81b@gmail.com>
 <DB7PR08MB33078ED1C29E120487256F87FF010@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <8dbfa656-54c5-44b3-d519-6fc32e6243fb@gmail.com>
 <aa75089f-0254-f552-85fb-5d2588a1c5b1@gmail.com>
 <06021b17-fe57-af7d-53ea-67efe879abfc@oracle.com>
 <013dc1bf-6aeb-97a5-69db-9ed0a559460b@gmail.com>
 <931dbe01-29f3-604b-1839-abde624f5445@oracle.com>
 <abc997a2-fd59-19f2-4b7e-e8221c17a61f@gmail.com>
 <7e202d75-da71-24c7-4bb3-bff919ff7942@oracle.com>
 <3d2763a8-fac9-69ad-7d2e-03184deb4138@gmail.com>
 <ceb5be7d-b8a5-cf94-be59-f5d8a7947cdb@oracle.com>
 <19af220e-d96f-6080-94e1-5119d36b4a93@oracle.com>
Message-ID: <CANkmnM43bRiqy7aMs1o3N+cO2k=LxH=v6HLfc+MaLUjSd5Kcgw@mail.gmail.com>

Hello Stuart,

Thank you very much for your help in sponsoring this as well as the
detailed reviews and suggestions.

-Jaikiran



On Thursday, September 27, 2018, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Hi, I just wanted to mention that I pushed the changeset for this bug:
>
>     http://hg.openjdk.java.net/jdk/jdk/rev/2ee7e1b7ba66
>
> Thanks for your contribution to OpenJDK!
>
> s'marks
>

From Sergey.Bylokhov at oracle.com  Thu Sep 27 03:23:10 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 26 Sep 2018 20:23:10 -0700
Subject: <Swing Dev> RFR; 8211031: Remove un-needed qualified export to
 java.desktop from java.base on macos
In-Reply-To: <5b2bde90-ca79-7496-4b1a-af2065066393@oracle.com>
References: <5BA550D7.6020104@oracle.com>
 <177e3a1c-0f50-328f-7bf1-95a55bea1e1a@oracle.com>
 <5BA5D225.3040002@oracle.com>
 <74630366-ddd2-503f-12f8-a3e3c8ecd037@oracle.com>
 <5b2bde90-ca79-7496-4b1a-af2065066393@oracle.com>
Message-ID: <15b9ec7c-b5c2-8186-a760-c81fc8d69d2b@oracle.com>

Looks fine.

On 26/09/2018 14:07, Phil Race wrote:
> Not 100% sure what happened there. I've re-uploaded it.
> Shift-reload to avoid browser caching and look again.
> 
> -phil.
> 
> On 09/26/2018 01:51 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> On 21/09/2018 22:24, Philip Race wrote:
>>> [*] at this exact moment, cr.openjdk.java.net isn't working but 
>>> hopefully
>>> that will be fixed by the time anyone reads this :-)
>>
>> The classExists() method still there in version .1
>>
>>
> 


-- 
Best regards, Sergey.

From pallavi.sonal at oracle.com  Thu Sep 27 04:34:51 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Wed, 26 Sep 2018 21:34:51 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
Message-ID: <0b15557a-a158-4f79-be93-d5a18ac950a2@default>

Thanks for the clarification. Here is the updated webrev for review :
http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ 

Thanks,
Pallavi Sonal

-----Original Message-----
From: Stephen Colebourne <scolebourne at joda.org> 
Sent: Tuesday, September 25, 2018 4:39 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

I think it makes sense for both, although I was only considering
appendInstant() when I wrote it.
Stephen


On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Hi Stephen,
> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Sunday, September 23, 2018 12:36 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> handle offsets
>
> Thanks
>
> Can we change the docs to:
>
> <p>
> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>
> thanks
> Stephen
>
>
> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
> >   http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
> >
> > Thanks,
> > Pallavi Sonal.
> >
> > -----Original Message-----
> > From: Stephen Colebourne <scolebourne at joda.org>
> > Sent: Thursday, September 20, 2018 6:38 PM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> > handle offsets
> >
> > Thanks for the update.
> >
> > The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
> > eg. a negative offset at MAX or a positive offset at MIN.
> >
> > The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
> >
> > thanks
> > Stephen
> >
> >
> > On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > >
> > > Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> > > Here is the updated webrev for review :
> > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
> > >
> > > Thanks,
> > > Pallavi Sonal
> > >
> > > -----Original Message-----
> > > From: Stephen Colebourne <scolebourne at joda.org>
> > > Sent: Thursday, September 20, 2018 2:50 AM
> > > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
> > > should handle offsets
> > >
> > > Thanks for looking at this.
> > >
> > > The proposed fix does not tackle the bug fully. The bug is that 
> > > the spec says
> > >
> > > "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
> > >
> > > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
> > >
> > > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> > > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
> > >
> > > Furthermore, although there are numerous valid ISO-8601 ways of 
> > > saying zero, this format uses dashes and colons in the date/time 
> > > part, so
> > > ISO-8601 restricts the offset to only those formats that include colons.
> > >
> > > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
> > >
> > > thanks
> > > Stephen
> > >
> > >
> > > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please review the changes to the following issue:
> > > >
> > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> > > >
> > > >
> > > >
> > > > The proposed fix is located at:
> > > >
> > > > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> > > >
> > > >
> > > >
> > > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> > > >
> > > >
> > > >
> > > > [1] https://en.wikipedia.org/wiki/ISO_8601
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Pallavi Sonal
> > > >
> > > >
> > > >
> > > >

From enasser at in.ibm.com  Thu Sep 27 05:42:07 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Thu, 27 Sep 2018 05:42:07 +0000
Subject: RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero
 from java.text.DecimalFormat.format()
In-Reply-To: <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
 <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
 <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
 <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>
Message-ID: <OF06D5763F.3F238A9A-ON00258315.001E04D6-65258315.001F5267@notes.na.collabserv.com>

Hi Joe, Naoto,

Thank you for your review comments. I agree with you that as per the VM 
specification, divide-by-zero in DecimalFormat is allowed and hence the 
current fix is more of a good to have rather than a defect fix. As Joe 
suggested, I will see whether the new fix give better performance in any 
platforms.

I think the current bug description may not be directly applicable to 
hotspot and a new bug explaining the behavior difference between before 
and after create JVM while handing SIGFPE may be better.

Regards, 
Nasser




From:   naoto.sato at oracle.com
To:     joe darcy <joe.darcy at oracle.com>, Nasser Ebrahim 
<enasser at in.ibm.com>, core-libs-dev Libs <core-libs-dev at openjdk.java.net>, 
"i18n-dev at openjdk.java.net" <i18n-dev at openjdk.java.net>
Date:   09/27/2018 01:55 AM
Subject:        Re: RFR: JDK-8211161: java.lang.ArithmeticException: 
divide by zero from java.text.DecimalFormat.format()



Hi, Nasser, Joe,

I agree with Joe as to the assessment on DecimalFormat code. The 
existing code looks correct. Unless there is any obvious need to replace 
the piece with bit operation, I'd just leave it as is. The jira issue 
can be transferred to HotSpot, though.

Naoto

On 9/26/18 11:14 AM, joe darcy wrote:
> Hi Nasser,
> 
> 
> On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
>> Hi Joe,
>>
>> Thank you for your review comments.
>>
>> I agree with you that the specification says that "The floating-point 
>> operations of the Java Virtual Machine do not throw exceptions, trap, 
>> or otherwise signal the IEEE 754 exceptional conditions of invalid 
>> operation, division by zero, overflow, underflow, or inexact." as per 
>> the JVM specification 
>> 
https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1
. 
>>
>>
>> I noticed that the SIGFPE is consumed and no exception is thrown when 
>> SIGFPE is enabled before create JVM. Hence, there is an inconsistency 
>> in the hotspot behavior when the SIGFPE is enabled before and after 
>> create JVM. If the trap is enabled before create JVM, it just catch 
>> the exception and continue where as if the trap is enabled after 
>> create JVM, then it result in the ArithmeticException.Hence, the JVM 
>> behavior needs to be fixed to make the behavior consistent.
>>
>> Still, I feel it makes more sense to check the sign bit to decide a 
>> number is negative or positive rather than divide-by-zro to make 
>> infinity and compare with zero. If you agree with my view, a separate 
>> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we 
>> can change the component of this bug. Please comment.
> 
> Here is my rephrasing of the situation:
> 
> If someone deliberately misconfigures a CPU such that its floating-point 

> behavior does not conform to the JVM specification, Java library code 
> throws unexpected exceptions.
> 
> In that case, it is not a bug in the library code, it is a problem 
> stemming from the deliberate CPU misconfiguration.
> 
> One could make a case that the new code is better in some way, perhaps 
> faster on some platforms, but it is functionally correct as is and 
> should not be described otherwise. The i18n team can weigh in with their 

> assessment of the proposed patch from a maintenance perspective.
> 
> The HotSpot team could evaluate if the VM implementation should be 
> further hardened against hostile changes to the FPU control word(s), but 

> I would be content if this issue were closed as not a bug.
> 
> Cheers,
> 
> -Joe






From christoph.langer at sap.com  Thu Sep 27 06:22:36 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Sep 2018 06:22:36 +0000
Subject: RFR: JDK-8211071: unpack.cpp fails to compile with statement has
 no effect [-Werror=unused-value]
In-Reply-To: <bb6d1c5f-a023-f8e9-6733-b68dc146ebbb@redhat.com>
References: <dd9fa3eb-c7ac-0c0f-2ddf-c3c5aec75bf9@redhat.com>
 <1654474A-1272-433C-9525-B0963E4298B3@oracle.com>
 <bb6d1c5f-a023-f8e9-6733-b68dc146ebbb@redhat.com>
Message-ID: <96cec4025f6e48f5943fa1ddc6142a28@sap.com>

Hi Roman,

this looks good to me. +1

Best regards
Christoph

> -----Original Message-----
> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of
> Roman Kennke
> Sent: Mittwoch, 26. September 2018 19:24
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; core-libs-
> dev at openjdk.java.net
> Cc: build-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8211071: unpack.cpp fails to compile with statement
> has no effect [-Werror=unused-value]
> 
> Ping core-libs?
> 
> Roman
> 
> Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
> >
> >> 25 sep. 2018 kl. 10:21 skrev Roman Kennke <rkennke at redhat.com>:
> >>
> >> Not sure this is the correct list. Please redirect as appropriate.
> >
> > I believe core-libs is the appropriate place. Cc:d.
> >
> >>
> >> Please review the following proposed change:
> >>
> >>
> >> There are 3 asserts in unpack.cpp which check only constants, and which
> >> the compiler rejects as 'has no effect' (in fastdebug builds). This
> >> seems to be caused by:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8211029
> >>
> >> I propose to fix this by defining a STATIC_ASSERT which can evaluate and
> >> reject this at compile time:
> >>
> >> Webrev:
> >> http://cr.openjdk.java.net/~rkennke/JDK-8211071/webrev.00/
> >
> > From a build perspective, this looks good. But please let someone from
> core-libs review also.
> >
> >> Bug:
> >> https://bugs.openjdk.java.net/browse/JDK-8211071
> >>
> >> It might be useful to define the STATIC_ASSERT in a more central place
> >> to be used elsewhere too. For example, there is a similar #define in
> >> Hotspot's debug.hpp
> >
> > Unfortunately, we do not have a good place to share definitions like this
> across JDK libraries. :-( The need for that has struck me more than once. For
> some stuff, we mis-use jni.h. But it would definitely be out of line to add a
> STATIC_ASSERT there.
> >
> > /Magnus
> >
> >>
> >> Thanks, Roman
> >>
> >


From rkennke at redhat.com  Thu Sep 27 07:02:00 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 27 Sep 2018 09:02:00 +0200
Subject: RFR: JDK-8211071: unpack.cpp fails to compile with statement has
 no effect [-Werror=unused-value]
In-Reply-To: <96cec4025f6e48f5943fa1ddc6142a28@sap.com>
References: <dd9fa3eb-c7ac-0c0f-2ddf-c3c5aec75bf9@redhat.com>
 <1654474A-1272-433C-9525-B0963E4298B3@oracle.com>
 <bb6d1c5f-a023-f8e9-6733-b68dc146ebbb@redhat.com>
 <96cec4025f6e48f5943fa1ddc6142a28@sap.com>
Message-ID: <db80fa8d-5eb2-a142-0655-72ec02ef23ae@redhat.com>

Hi Christoph & Magnus, thanks for reviewing!

Am 27.09.18 um 08:22 schrieb Langer, Christoph:
> Hi Roman,
> 
> this looks good to me. +1
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of
>> Roman Kennke
>> Sent: Mittwoch, 26. September 2018 19:24
>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; core-libs-
>> dev at openjdk.java.net
>> Cc: build-dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8211071: unpack.cpp fails to compile with statement
>> has no effect [-Werror=unused-value]
>>
>> Ping core-libs?
>>
>> Roman
>>
>> Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
>>>
>>>> 25 sep. 2018 kl. 10:21 skrev Roman Kennke <rkennke at redhat.com>:
>>>>
>>>> Not sure this is the correct list. Please redirect as appropriate.
>>>
>>> I believe core-libs is the appropriate place. Cc:d.
>>>
>>>>
>>>> Please review the following proposed change:
>>>>
>>>>
>>>> There are 3 asserts in unpack.cpp which check only constants, and which
>>>> the compiler rejects as 'has no effect' (in fastdebug builds). This
>>>> seems to be caused by:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8211029
>>>>
>>>> I propose to fix this by defining a STATIC_ASSERT which can evaluate and
>>>> reject this at compile time:
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8211071/webrev.00/
>>>
>>> From a build perspective, this looks good. But please let someone from
>> core-libs review also.
>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8211071
>>>>
>>>> It might be useful to define the STATIC_ASSERT in a more central place
>>>> to be used elsewhere too. For example, there is a similar #define in
>>>> Hotspot's debug.hpp
>>>
>>> Unfortunately, we do not have a good place to share definitions like this
>> across JDK libraries. :-( The need for that has struck me more than once. For
>> some stuff, we mis-use jni.h. But it would definitely be out of line to add a
>> STATIC_ASSERT there.
>>>
>>> /Magnus
>>>
>>>>
>>>> Thanks, Roman
>>>>
>>>
> 


From scolebourne at joda.org  Thu Sep 27 07:39:38 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 27 Sep 2018 08:39:38 +0100
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
Message-ID: <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>

In DateTimeFormatter you need to qualify the @code part to refer to
DateTimeFormatterBuilder.
Otherwise good.
thanks
Stephen


On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>
> Thanks for the clarification. Here is the updated webrev for review :
> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>
> Thanks,
> Pallavi Sonal
>
> -----Original Message-----
> From: Stephen Colebourne <scolebourne at joda.org>
> Sent: Tuesday, September 25, 2018 4:39 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>
> I think it makes sense for both, although I was only considering
> appendInstant() when I wrote it.
> Stephen
>
>
> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> >
> > Hi Stephen,
> > Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
> >
> > -----Original Message-----
> > From: Stephen Colebourne <scolebourne at joda.org>
> > Sent: Sunday, September 23, 2018 12:36 PM
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
> > handle offsets
> >
> > Thanks
> >
> > Can we change the docs to:
> >
> > <p>
> > When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
> > When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
> >
> > thanks
> > Stephen
> >
> >
> > On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > >
> > > Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
> > >   http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
> > >
> > > Thanks,
> > > Pallavi Sonal.
> > >
> > > -----Original Message-----
> > > From: Stephen Colebourne <scolebourne at joda.org>
> > > Sent: Thursday, September 20, 2018 6:38 PM
> > > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
> > > handle offsets
> > >
> > > Thanks for the update.
> > >
> > > The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
> > > eg. a negative offset at MAX or a positive offset at MIN.
> > >
> > > The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
> > >
> > > thanks
> > > Stephen
> > >
> > >
> > > On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > > >
> > > > Thanks Roger , Naoto and Stephen for the review and valuable inputs.
> > > > Here is the updated webrev for review :
> > > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
> > > >
> > > > Thanks,
> > > > Pallavi Sonal
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Colebourne <scolebourne at joda.org>
> > > > Sent: Thursday, September 20, 2018 2:50 AM
> > > > To: core-libs-dev <core-libs-dev at openjdk.java.net>
> > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
> > > > should handle offsets
> > > >
> > > > Thanks for looking at this.
> > > >
> > > > The proposed fix does not tackle the bug fully. The bug is that
> > > > the spec says
> > > >
> > > > "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
> > > >
> > > > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
> > > >
> > > > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
> > > > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
> > > >
> > > > Furthermore, although there are numerous valid ISO-8601 ways of
> > > > saying zero, this format uses dashes and colons in the date/time
> > > > part, so
> > > > ISO-8601 restricts the offset to only those formats that include colons.
> > > >
> > > > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
> > > >
> > > > thanks
> > > > Stephen
> > > >
> > > >
> > > > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Please review the changes to the following issue:
> > > > >
> > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
> > > > >
> > > > >
> > > > >
> > > > > The proposed fix is located at:
> > > > >
> > > > > Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
> > > > >
> > > > >
> > > > >
> > > > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
> > > > >
> > > > >
> > > > >
> > > > > [1] https://en.wikipedia.org/wiki/ISO_8601
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Pallavi Sonal
> > > > >
> > > > >
> > > > >
> > > > >

From raffaello.giulietti at gmail.com  Thu Sep 27 08:36:20 2018
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 27 Sep 2018 10:36:20 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <2E379E99-31FC-4902-9359-B79E3B0D8078@oracle.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <AEEF4C78-E288-47B8-B26F-BCB6BA8E24D9@oracle.com>
 <56360329-70C3-48BF-9A8B-7C63C3F2D3F4@oracle.com>
 <2E379E99-31FC-4902-9359-B79E3B0D8078@oracle.com>
Message-ID: <4b327724-3b02-6eea-35c1-3039a80b0a21@gmail.com>

Hi Brian,

On 2018-09-27 01:53, Brian Burkhalter wrote:
> There was a compilation error on Linux in one of the tests:
> 
> test/jdk/java/lang/Floating/DoubleToDecString.java:133: error: unmappable character (0x93) for encoding US-ASCII
>      Paxson V, "A Program for Testing IEEE Decimal\ufffd\ufffd\ufffdBinary Conversion"
> 
> This was only in one of the comments where it looks like some errant character leaked in. I updated the webrev (with accompanying patch) in place [1] after verifying that the change to the test fixes the problem.
> 

I can confirm that in my original source there is a 'EN DASH' (U+2013) 
Unicode character, which visually looks similar to 'HYPHEN-MINUS' 
(U+002D). I use UTF-8 on all my source files, so it didn't stand out as 
something strange in the IDE.

This is certainly due to some copy&paste operation from a source found 
on the internet. U+2013 is the correct variant, both semantically and 
typographically, but it surely causes problems with tools that expect 
US-ASCII. Frankly, there should be no such restrictions in tools, as 
Java supports Unicode source code since day 0, but that's another story.

For this project, I will switch to US-ASCII in my IDE.



> Also, there were a couple of failures observed in test [2] at lines 172 and 173. If at line 172 "foo1.17549435E-38? is changed to "foo1.1754944E-38? then the evaluation at that line succeeds but then the one at line 173 fails. Making a similar change on this line does not help. I suspect that this is due to a difference between the new code and that in jdk.internal.math.FloatingDecimal which is used by java.lang.AbstractStringBuilder and java.lang.invoke.StringConcatFactory but I?ve not actually investigated this as yet. I had actually wondered whether some or all of the FloatingDecimal code could be superseded by the updated logic.
> 

"1.1754944E-38" is shorter than "1.17549435E-38" and can still recover 
Float.MIN_NORMAL. That's why the new code returns the shorter variant.

Why this works when the replacement is made in line 172 but not in line 
173 is really counter-intuitive. The only superficial difference is that 
FLOAT_MIN_NORM_1 is declared final while FLOAT_MIN_NORM_2 is not, 
although both are initialized with the same value.

The black-box conclusion is that it seems that string concatenation 
performed at compile time and at runtime manages to produce different 
results when given the same values. This is of course a problem outside 
the scope of the Double/Float conversions. As you point out, a more 
white-box analysis might reveal the culprit in the deadly embrace 
between string building and FloatingDecimal.

Unfortunately, I won't have time to investigate this interesting issue 
further before the weekend.


Greetings
Raffaello




> Brian
> 
> [1] http://cr.openjdk.java.net/~bpb/4511638/webrev.00/
> [2] java/lang/String/concat/ImplicitStringConcatBoundaries.java
> 


From Alan.Bateman at oracle.com  Thu Sep 27 08:45:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Sep 2018 09:45:18 +0100
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
Message-ID: <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>

On 27/09/2018 03:58, Henry Jen wrote:
> Hi,
>
> Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.
>
> I had reviewed the change and tested, but we need a ?R?eviewer.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
> [2] https://bugs.openjdk.java.net/browse/JDK-8210810
>
>
The change to args.c looks okay but for the test then I assume it would 
be better to just add another test case to the existing ArgFileSyntax.java.

-Alan

From zhangbodut at gmail.com  Thu Sep 27 08:59:08 2018
From: zhangbodut at gmail.com (Bo Zhang)
Date: Thu, 27 Sep 2018 16:59:08 +0800
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
Message-ID: <06249457-65D3-4AEC-A9D7-B09B727A4F32@gmail.com>

Yes, that would be better. Please feel free to move it.

> On 27 Sep 2018, at 16:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 27/09/2018 03:58, Henry Jen wrote:
>> Hi,
>> 
>> Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.
>> 
>> I had reviewed the change and tested, but we need a ?R?eviewer.
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8210810
>> 
>> 
> The change to args.c looks okay but for the test then I assume it would be better to just add another test case to the existing ArgFileSyntax.java.
> 
> -Alan


From aph at redhat.com  Thu Sep 27 09:03:28 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 27 Sep 2018 10:03:28 +0100
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
Message-ID: <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>

On 09/26/2018 06:39 PM, raffaello.giulietti at gmail.com wrote:

> The submitted code contains both the changes to the current
> implementation and extensive jtreg tests.
>
> While I've struggled to keep the code within the 80 chars/line limit,
> mercurial still generates longer lines. Thus, to avoid possible problems
> with the email systems, the code is submitted both inline and as an
> attachment. Hope at least one copy makes its way without errors.

Overall, the commenting is much too light. There are many places
where I think I know what you're doing but you don't explain it.

Here, for example:

> +
> +        // pow5 = pow51*2^63 + pow50
> +        long pow51 = ceilPow5dHigh(-k);
> +        long pow50 = ceilPow5dLow(-k);
> +
> +        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
> +        long x0 = pow50 * cb;
> +        long x1 = multiplyHigh(pow50, cb);
> +        long y0 = pow51 * cb;
> +        long y1 = multiplyHigh(pow51, cb);
> +        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
> +        long p0 = x0 & MASK_63;
> +        long p1 = z & MASK_63;
> +        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
> +        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
> +        if ((p1 & mask) != 0 || p0 >= threshold) {
> +            vn |= 1;
> +        }

... etc. I think I can figure out what you're doing, but you could
explain it.

If you write the comments now while the code is still fresh in your
mind it'll be easy.

> +    private static final long[] ceilPow5d = {
> +        /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL,
> +        /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL,
> +        /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L,
> +        /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L,

What exactly is this table anyway?  How was it generated?  Please say.

There are many more places in the code. What you've done is nice, but
it could be exemplary.

-- 
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 adinn at redhat.com  Thu Sep 27 09:23:05 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 27 Sep 2018 10:23:05 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
Message-ID: <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>

On 26/09/18 17:00, Alan Bateman wrote:
> The reason that we've mentioned it a few times is because it's a
> significant issue. If you have a byte buffer then you can't have
> different threads accessing different parts of the buffer at the same
> time, at least not with any of the relative get/put methods as they
> depend on the buffer position. Sure you can globally synchronize all
> operations but you'll likely want much finer granularity. This bugbear
> comes up periodically, particularly when using buffers for cases that
> they weren't really designed for. Stuart pointed out the lack of
> absolute bulk get/put operations which is something that I think will
> help some of these cases.

Ok, I see that there is an issue here where only byte puts at absolute
positions can be performed concurrently (assuming threads know how to
avoid overlapping writes) while, by contrast, cursor-based byte[] stores
require synchronization. Is that the problem in full? Or is there still
more that I have missed?

I certainly agree that a retro-fit to ByteBuffer which provided for
byte[] puts at absolute positions would be of benefit for this proposal.
However, such a retro-fix would be equally as useful for volatile memory
buffers. I am not clear why this omission suggests to you that we should
look at a new, alternative model for managing this particular type of
mapped memory rather than just fixing the current one properly for all
buffers.

>> Also, can you explain what you mean by confinement? (thread
>> confinement?).
> Yes, thread vs. global. I haven't been following Panama close enough to
> say how this is exposed in the API.

Well, my vague stab was obviously in the right ballpark but I'm afraid I
still don't know what baseball is. Could you explain what you mean by
confinement?

>> Also, I don't think I would label this API an attempt to develop a file
>> system. I think that's rather and overblown characterisation of what it
>> does.
> I think you may have mis-read my mail as was just picking another
> example where MBB would be problematic.

Apologies for my very evident confusion here. I'd be very grateful if
you could talk down a notch or two and/or amplify a bit more to help the
hard of thinking.

>> I'm still not quite sure where this reply leaves the JEP though. Shall I
>> update the Risks and Assumptions section to include mention of
>> JDK-5029431 as suggested to Stuart? Is there anything else I can do to
>> progress things?
>>
> It wouldn't do any harm to have this section mention that an alternative
> that exposes a more memory centric API may be possible in the future.
Ok, I'll certainly add that.

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 peter.levart at gmail.com  Thu Sep 27 10:28:21 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 27 Sep 2018 12:28:21 +0200
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <6b29fde7-c147-a346-6bee-c410c57c498d@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
Message-ID: <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>

Hi Andrew,

On 09/27/2018 11:23 AM, Andrew Dinn wrote:
> On 26/09/18 17:00, Alan Bateman wrote:
>> The reason that we've mentioned it a few times is because it's a
>> significant issue. If you have a byte buffer then you can't have
>> different threads accessing different parts of the buffer at the same
>> time, at least not with any of the relative get/put methods as they
>> depend on the buffer position. Sure you can globally synchronize all
>> operations but you'll likely want much finer granularity. This bugbear
>> comes up periodically, particularly when using buffers for cases that
>> they weren't really designed for. Stuart pointed out the lack of
>> absolute bulk get/put operations which is something that I think will
>> help some of these cases.
> Ok, I see that there is an issue here where only byte puts at absolute
> positions can be performed concurrently (assuming threads know how to
> avoid overlapping writes) while, by contrast, cursor-based byte[] stores
> require synchronization. Is that the problem in full? Or is there still
> more that I have missed?
>
> I certainly agree that a retro-fit to ByteBuffer which provided for
> byte[] puts at absolute positions would be of benefit for this proposal.
> However, such a retro-fix would be equally as useful for volatile memory
> buffers. I am not clear why this omission suggests to you that we should
> look at a new, alternative model for managing this particular type of
> mapped memory rather than just fixing the current one properly for all
> buffers.

May I just note that multithreaded bulk operations are kind of possible 
without external synchronization (i.e. locks) if you follow a simple 
protocol:

- never use relative operations on the shared ByteBuffer instance
- never use operations that change internal 
mark/position/limit/byteOrder on the shared ByteBuffer instance
- a concurrent bulk operation on 'bb' consists of:

ByteBuffer myBb = bb.slice(0, bb.capacity());
// use myBb to perform concurrent bulk operation (any operations are 
allowed) and then throw it away or cache it in ThreadLocal

If you combine this with explicit fences and/or atomic 16, 32 and 64 bit 
operations via VarHandles. (see 
MethodHandles.byteBufferViewVarHandle(Class, ByteOrder)), concurrent 
programming with ByteBuffer(s) is entirely possible.

Regards, Peter

>
>>> Also, can you explain what you mean by confinement? (thread
>>> confinement?).
>> Yes, thread vs. global. I haven't been following Panama close enough to
>> say how this is exposed in the API.
> Well, my vague stab was obviously in the right ballpark but I'm afraid I
> still don't know what baseball is. Could you explain what you mean by
> confinement?
>
>>> Also, I don't think I would label this API an attempt to develop a file
>>> system. I think that's rather and overblown characterisation of what it
>>> does.
>> I think you may have mis-read my mail as was just picking another
>> example where MBB would be problematic.
> Apologies for my very evident confusion here. I'd be very grateful if
> you could talk down a notch or two and/or amplify a bit more to help the
> hard of thinking.
>
>>> I'm still not quite sure where this reply leaves the JEP though. Shall I
>>> update the Risks and Assumptions section to include mention of
>>> JDK-5029431 as suggested to Stuart? Is there anything else I can do to
>>> progress things?
>>>
>> It wouldn't do any harm to have this section mention that an alternative
>> that exposes a more memory centric API may be possible in the future.
> Ok, I'll certainly add that.
>
> 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 adinn at redhat.com  Thu Sep 27 10:41:11 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 27 Sep 2018 11:41:11 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
Message-ID: <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>

Hi Peter,

On 27/09/18 11:28, Peter Levart wrote:

> May I just note that multithreaded bulk operations are kind of possible
> without external synchronization (i.e. locks) if you follow a simple
> protocol:
> 
> - never use relative operations on the shared ByteBuffer instance
> - never use operations that change internal
> mark/position/limit/byteOrder on the shared ByteBuffer instance
> - a concurrent bulk operation on 'bb' consists of:
> 
> ByteBuffer myBb = bb.slice(0, bb.capacity());
> // use myBb to perform concurrent bulk operation (any operations are
> allowed) and then throw it away or cache it in ThreadLocal
> 
> If you combine this with explicit fences and/or atomic 16, 32 and 64 bit
> operations via VarHandles. (see
> MethodHandles.byteBufferViewVarHandle(Class, ByteOrder)), concurrent
> programming with ByteBuffer(s) is entirely possible.
Thank you for the usual expert advice. I am sure it will be of great
help in implementing a persistent data management library over this
JEP's base capability.

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 chris.hegarty at oracle.com  Thu Sep 27 10:49:28 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 27 Sep 2018 11:49:28 +0100
Subject: RFR: jsr166 integration 2018-09
In-Reply-To: <CA+kOe09LJ9hZ1v50q3bfLeymhSsXgY6j8FMT9RJnGYbkLd-otA@mail.gmail.com>
References: <CA+kOe09LJ9hZ1v50q3bfLeymhSsXgY6j8FMT9RJnGYbkLd-otA@mail.gmail.com>
Message-ID: <7BE1FCD3-AEA4-47B3-B842-06F5CD257908@oracle.com>


> On 26 Sep 2018, at 19:53, Martin Buchholz <martinrb at google.com> wrote:
> 
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
> 
> 8210971: Add exception handling methods to CompletionStage and CompletableFuture
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/exceptionally/index.html
> https://bugs.openjdk.java.net/browse/JDK-8210971 <https://bugs.openjdk.java.net/browse/JDK-8210971>

Nice to see this one coming in. We have some cleanup in other
areas that can leverage some of these new methods.

> 8207003: Miscellaneous changes imported from jsr166 CVS 2018-09
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
> https://bugs.openjdk.java.net/browse/JDK-8207003 <https://bugs.openjdk.java.net/browse/JDK-8207003>

These look fine to me Martin.

-Chris.


From raffaello.giulietti at gmail.com  Thu Sep 27 12:23:30 2018
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 27 Sep 2018 14:23:30 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
Message-ID: <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>

Hi Andrew,

In principle I agree with you.

However, in this case the maths underlying the algorithm to select the 
decimal are too involved to explain in comment form. I'm in the course 
of preparing a paper that explains the idea and the details. Then it 
should be easier to make sense out of the code.

Since to my knowledge the algorithm is novel, it will require some time 
for me to translate in paper form.

Other observations are interspersed with yours below.



On 2018-09-27 11:03, Andrew Haley wrote:
> On 09/26/2018 06:39 PM, raffaello.giulietti at gmail.com wrote:
> 
>> The submitted code contains both the changes to the current
>> implementation and extensive jtreg tests.
>>
>> While I've struggled to keep the code within the 80 chars/line limit,
>> mercurial still generates longer lines. Thus, to avoid possible problems
>> with the email systems, the code is submitted both inline and as an
>> attachment. Hope at least one copy makes its way without errors.
> 
> Overall, the commenting is much too light. There are many places
> where I think I know what you're doing but you don't explain it.
> 
> Here, for example:
> 
>> +
>> +        // pow5 = pow51*2^63 + pow50
>> +        long pow51 = ceilPow5dHigh(-k);
>> +        long pow50 = ceilPow5dLow(-k);
>> +
>> +        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
>> +        long x0 = pow50 * cb;
>> +        long x1 = multiplyHigh(pow50, cb);
>> +        long y0 = pow51 * cb;
>> +        long y1 = multiplyHigh(pow51, cb);
>> +        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
>> +        long p0 = x0 & MASK_63;
>> +        long p1 = z & MASK_63;
>> +        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
>> +        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
>> +        if ((p1 & mask) != 0 || p0 >= threshold) {
>> +            vn |= 1;
>> +        }
> 
> ... etc. I think I can figure out what you're doing, but you could
> explain it.
> 
 > If you write the comments now while the code is still fresh in your
 > mind it'll be easy.
 >

There are some succinct comments here that explain the expected results. 
I'm not the kind of programmer that comments every line since here the 
mechanics is simple enough to follow in Java directly. A good 
explanation would either be mathematical, which requires better 
typography than US-ASCII, or some explanatory drawings.

What the semantics of vn, vnl and vnr are will be explained in the 
future paper mentioned above.



>> +    private static final long[] ceilPow5d = {
>> +        /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL,
>> +        /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL,
>> +        /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L,
>> +        /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L,
> 
> What exactly is this table anyway?  How was it generated?  Please say.
> 

The comments of the accessor methods that make use of this private table 
implicitly explain its semantics as well. I will add a comment to the 
field that refers to the comments in the methods.


How the table was generated and thoroughly verified is currently not 
part of my contribution to OpenJDK, not because it is something secret 
or complex but because I think it is irrelevant here.

Besides, where would the generator/verifier code be placed in the 
codebase? It would be completely detached from, and unrelated to, 
everything else. But maybe there is already some mechanism in place for 
similar "bootstrapping" code in the OpenJDK. Then I would like to know 
to consider adding the generator there.


> There are many more places in the code. What you've done is nice, but
> it could be exemplary.
> 

As said, this will be part of a separate paper. Hope this helps for the 
moment.


Thanks for your interest
Raffaello

From adinn at redhat.com  Thu Sep 27 12:57:02 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 27 Sep 2018 13:57:02 +0100
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
Message-ID: <1af924fb-2281-22a7-fe1d-91822e7a95c1@redhat.com>

On 27/09/18 13:23, Raffaello Giulietti wrote:
  . . .
> The comments of the accessor methods that make use of this private table
> implicitly explain its semantics as well. I will add a comment to the
> field that refers to the comments in the methods.
> 
> 
> How the table was generated and thoroughly verified is currently not
> part of my contribution to OpenJDK, not because it is something secret
> or complex but because I think it is irrelevant here.

I suspect it would be far from irrelevant to someone faced with
debugging and fixing any future problem found in the code. Of course,
you may well still be around to fix it but we don't know that for sure.

> Besides, where would the generator/verifier code be placed in the
> codebase? It would be completely detached from, and unrelated to,
> everything else. But maybe there is already some mechanism in place for
> similar "bootstrapping" code in the OpenJDK. Then I would like to know
> to consider adding the generator there.

We don't absolutely need generator/verifier code (although the latter
might be helpful). The problem we face is what to do if a bug is found.
Could it simply be a table entry that is wrong or is there a detail of
the algorithm that has been mis-encoded? How would we tell?

If we have an explanation of /how/ the provided values were derived and
/why/ so derived then that would allow any such bugs to be resolved much
more easily. Omitting that background risks turning this into a one-shot
code drop rather than a very welcome contribution.

>> There are many more places in the code. What you've done is nice, but
>> it could be exemplary.
>>
> 
> As said, this will be part of a separate paper. Hope this helps for the
> moment.
Sure, a reference to a published doc would be great - assuming it makes
it clear how the quite code is derived from the maths/algorithm it
details. I'd really much prefer to have that doc before accepting the
code just in order to be sure that there is no gap between theory and
execution that some judicious commenting might close. Having recently
reviewed some math code for log, trig and power functions I am well
aware how details of specific coding operations are not always clearly
identifiable from an abstract mathematical treatment. Even when they can
be derived a few comments in the code often help avoid any resort to a
pencil and thick pad of graph paper.

When you do post a link to the paper I'll be willing to check it and
hope that I will, if needed, be able to ask you for advice to help
clarify any such gap.

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 aph at redhat.com  Thu Sep 27 13:28:38 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 27 Sep 2018 14:28:38 +0100
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
Message-ID: <8c2e04a9-fcc1-4d77-5a08-3ca136288c25@redhat.com>

On 09/27/2018 01:23 PM, Raffaello Giulietti wrote:

> In principle I agree with you.
> 
> However, in this case the maths underlying the algorithm to select the 
> decimal are too involved to explain in comment form. I'm in the course 
> of preparing a paper that explains the idea and the details. Then it 
> should be easier to make sense out of the code.

In which case, the code must contain pointers to the relevant parts of
the paper.

> Since to my knowledge the algorithm is novel, it will require some time 
> for me to translate in paper form.

Sure, but how do you expect anyone to review your code without the
necessary explanation? Do you think that people should approve your
patch without that paper?

> There are some succinct comments here that explain the expected
> results.  I'm not the kind of programmer that comments every line
> since here the mechanics is simple enough to follow in Java
> directly. A good explanation would either be mathematical, which
> requires better typography than US-ASCII, or some explanatory
> drawings.

Sure, these can be offline somewhere. The difficulty is always the
mapping from the mathematics onto the Java code, and this is what must
be explained in the comments.

-- 
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 raffaello.giulietti at gmail.com  Thu Sep 27 13:42:05 2018
From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com)
Date: Thu, 27 Sep 2018 15:42:05 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <1af924fb-2281-22a7-fe1d-91822e7a95c1@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
 <1af924fb-2281-22a7-fe1d-91822e7a95c1@redhat.com>
Message-ID: <2e6f3bdf-394c-9709-f277-b26026884b1a@gmail.com>

Hi Andrew,


On 2018-09-27 14:57, Andrew Dinn wrote:
> On 27/09/18 13:23, Raffaello Giulietti wrote:
>   . . .
>> The comments of the accessor methods that make use of this private table
>> implicitly explain its semantics as well. I will add a comment to the
>> field that refers to the comments in the methods.
>>
>>
>> How the table was generated and thoroughly verified is currently not
>> part of my contribution to OpenJDK, not because it is something secret
>> or complex but because I think it is irrelevant here.
> 
> I suspect it would be far from irrelevant to someone faced with
> debugging and fixing any future problem found in the code. Of course,
> you may well still be around to fix it but we don't know that for sure.
> 
>> Besides, where would the generator/verifier code be placed in the
>> codebase? It would be completely detached from, and unrelated to,
>> everything else. But maybe there is already some mechanism in place for
>> similar "bootstrapping" code in the OpenJDK. Then I would like to know
>> to consider adding the generator there.
> 
> We don't absolutely need generator/verifier code (although the latter
> might be helpful). The problem we face is what to do if a bug is found.
> Could it simply be a table entry that is wrong or is there a detail of
> the algorithm that has been mis-encoded? How would we tell?
> > If we have an explanation of /how/ the provided values were derived and
> /why/ so derived then that would allow any such bugs to be resolved much
> more easily. Omitting that background risks turning this into a one-shot
> code drop rather than a very welcome contribution.
> 

As mentioned in my previous post, the explanation of *what* the table
represents is implicitly and rigorously explained in the comments of the
methods that make use of it. That should make it easy to verify that the
table is sound.

As of the *how*, the generator is based on BigInteger arithmetic and
both generates and verifies the results. What I can do is to add the
code in the MathUtils class itself. It would never be run except for
diagnosis. But then one has to trust BigInteger.

The *why* will be part of the paper.



>>> There are many more places in the code. What you've done is nice, but
>>> it could be exemplary.
>>>
>>
>> As said, this will be part of a separate paper. Hope this helps for the
>> moment.
> Sure, a reference to a published doc would be great - assuming it makes
> it clear how the quite code is derived from the maths/algorithm it
> details. I'd really much prefer to have that doc before accepting the
> code just in order to be sure that there is no gap between theory and
> execution that some judicious commenting might close. Having recently
> reviewed some math code for log, trig and power functions I am well
> aware how details of specific coding operations are not always clearly
> identifiable from an abstract mathematical treatment. Even when they can
> be derived a few comments in the code often help avoid any resort to a
> pencil and thick pad of graph paper.
> 
> When you do post a link to the paper I'll be willing to check it and
> hope that I will, if needed, be able to ask you for advice to help
> clarify any such gap.
> 

The paper will explain the theory and the details.



From raffaello.giulietti at gmail.com  Thu Sep 27 14:20:54 2018
From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com)
Date: Thu, 27 Sep 2018 16:20:54 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <8c2e04a9-fcc1-4d77-5a08-3ca136288c25@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
 <8c2e04a9-fcc1-4d77-5a08-3ca136288c25@redhat.com>
Message-ID: <79485c16-207a-c2f3-d274-f64388b91658@gmail.com>

Hi Andrew,

On 2018-09-27 15:28, Andrew Haley wrote:
> On 09/27/2018 01:23 PM, Raffaello Giulietti wrote:
> 
>> In principle I agree with you.
>>
>> However, in this case the maths underlying the algorithm to select the 
>> decimal are too involved to explain in comment form. I'm in the course 
>> of preparing a paper that explains the idea and the details. Then it 
>> should be easier to make sense out of the code.
> 
> In which case, the code must contain pointers to the relevant parts of
> the paper.
> 

Sure.


>> Since to my knowledge the algorithm is novel, it will require some time 
>> for me to translate in paper form.
> 
> Sure, but how do you expect anyone to review your code without the
> necessary explanation? Do you think that people should approve your
> patch without that paper?
> 

I've no idea on how OpenJDK code is reviewed, so I cannot honestly
answer your questions. What I can tell is that if I were a reviewer, I
wouldn't trust rather involved code like mine without an explanation,
exactly as you seem inclined to do.

On the other side, in April this year I submitted another quite fast and
supposedly correct algorithm on this mailing list and I referred to an
accompanying paper by myself that gives full explanations on that
variant. Except for a couple of persons in private, nobody cared to send
me any observation or comment, neither on the code nor on the paper.

The present algorithm is superior. I have the theory in notes, in my
head, on napkins, on paper sheets all over my desk and floors. But
rather than spending time on the paper itself, like I did almost in vain
for the April variant, I preferred investing it in coding, for several
reasons:
* Only code executes, not a paper.
* Only code gives results that can be compared against.
* Only code can give indications on performance enhancements.
* Only code is interesting to be submitted to the OpenJDK.
* Having a paper without having tried the ideas in code is half the fun
and half as useful.

It's only a matter of priorities and of limited time, my spare time.
That said, now that I have some feedback and that the code has been
exercised at least some 400 billions times on doubles without errors and
on all 2^32 floats without errors, I now know that there is some
interest and that it is worth pushing energies in the paper.



>> There are some succinct comments here that explain the expected
>> results.  I'm not the kind of programmer that comments every line
>> since here the mechanics is simple enough to follow in Java
>> directly. A good explanation would either be mathematical, which
>> requires better typography than US-ASCII, or some explanatory
>> drawings.
> 
> Sure, these can be offline somewhere. The difficulty is always the
> mapping from the mathematics onto the Java code, and this is what must
> be explained in the comments.
> 

... or in the paper.


Greetings
Raffaello




From ulfjack at google.com  Thu Sep 27 14:40:04 2018
From: ulfjack at google.com (Ulf Adams)
Date: Thu, 27 Sep 2018 16:40:04 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
Message-ID: <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>

Hi Raffaello,

I am the author of a recent publication on double to string conversion [1]
- the Ryu algorithm. I've been aware of the problems with the Jdk for
several years, and am very much looking forward to improvements in
correctness and performance in this area.

I have done some testing against my Java implementation of the Ryu
algorithm described in the linked paper. Interestingly, I've found a few
cases where they output different results. In particular:
1.0E-323 is printed as 9.9E-324
1.0E-322 is printed as 9.9E-323

It's likely that there are more such cases - I only ran a sample of
double-precision numbers. Arguably, 9.9 is the correctly rounded 2-digit
output and Ryu is incorrect here. That's what you get when you have a
special case for Java without a correctness proof. :-(

In terms of performance, this algorithm performs almost exactly the same as
my Java implementation of Ryu, although I'd like to point out that my C
implementation of Ryu is quite a bit faster (though note that it generates
different output, in particular, it only outputs a single digit of
precision in the above cases, rather than two), and I didn't backport all
the performance improvements from the Java version, yet. It looks like this
is not coincidence - as far as I can see so far, it's algorithmically very
similar, although it manages to avoid the loop I'm using in Ryu to find the
shortest representation.

I have a few comments:

     *     <li> It rounds to {@code v} according to the usual
round-to-closest
     *     rule of IEEE 754 floating-point arithmetic.
- Since you're spelling out the rounding rules just below, this is
duplicated, and by itself, it's unclear since it doesn't specify the
specific sub-type (round half even).

- Naming: I'd strongly suggest to use variable names that relate to what's
stored, e.g., m for mantissa, e for exponent, etc.

- What's not clear to me is how the algorithm determines how many digits to
print.

- Also, it might be nicer to move the long multiplications to a helper
method - at least from a short look, it looks like the computations of vn,
vnl, and vnr are identical.

- I looked through the spec, and it looks like all cases are well-defined.
Yay!

I will need some more time to do a more thorough review of the code and
more testing for differences. Unfortunately, I'm also traveling the next
two weeks, so this might take a bit of time.

I'm not a contributor to the Jdk, and this isn't my full-time job. I was
lurking here because I was going to send a patch for the double to string
conversion code myself (based on Ryu).

Thanks,

-- Ulf

[1] https://dl.acm.org/citation.cfm?id=3192369
[2] https://github.com/google/double-conversion
[3] https://en.wikipedia.org/wiki/Rounding

On Thu, Sep 27, 2018 at 11:03 AM Andrew Haley <aph at redhat.com> wrote:

> On 09/26/2018 06:39 PM, raffaello.giulietti at gmail.com wrote:
>
> > The submitted code contains both the changes to the current
> > implementation and extensive jtreg tests.
> >
> > While I've struggled to keep the code within the 80 chars/line limit,
> > mercurial still generates longer lines. Thus, to avoid possible problems
> > with the email systems, the code is submitted both inline and as an
> > attachment. Hope at least one copy makes its way without errors.
>
> Overall, the commenting is much too light. There are many places
> where I think I know what you're doing but you don't explain it.
>
> Here, for example:
>
> > +
> > +        // pow5 = pow51*2^63 + pow50
> > +        long pow51 = ceilPow5dHigh(-k);
> > +        long pow50 = ceilPow5dLow(-k);
> > +
> > +        // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb
> > +        long x0 = pow50 * cb;
> > +        long x1 = multiplyHigh(pow50, cb);
> > +        long y0 = pow51 * cb;
> > +        long y1 = multiplyHigh(pow51, cb);
> > +        long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63);
> > +        long p0 = x0 & MASK_63;
> > +        long p1 = z & MASK_63;
> > +        long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63);
> > +        long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha;
> > +        if ((p1 & mask) != 0 || p0 >= threshold) {
> > +            vn |= 1;
> > +        }
>
> ... etc. I think I can figure out what you're doing, but you could
> explain it.
>
> If you write the comments now while the code is still fresh in your
> mind it'll be easy.
>
> > +    private static final long[] ceilPow5d = {
> > +        /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL,
> > +        /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL,
> > +        /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L,
> > +        /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L,
>
> What exactly is this table anyway?  How was it generated?  Please say.
>
> There are many more places in the code. What you've done is nice, but
> it could be exemplary.
>
> --
> 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 matthias.baesken at sap.com  Thu Sep 27 14:42:50 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 27 Sep 2018 14:42:50 +0000
Subject: [XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID
 after failing SetupI18nProps call [windows]
In-Reply-To: <4f53658d-1014-03e9-f5cb-3d1c41ae246c@oracle.com>
References: <VI1PR02MB43842C138735904D7C1FEF3193150@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <4f53658d-1014-03e9-f5cb-3d1c41ae246c@oracle.com>
Message-ID: <VI1PR02MB4384FCE6999829B99C44A15293140@VI1PR02MB4384.eurprd02.prod.outlook.com>

Hi,  thanks for your comments, I posted a second webrev  : 

http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.1/webrev/

Best regards, Matthias


> -----Original Message-----
> From: naoto.sato at oracle.com <naoto.sato at oracle.com>
> Sent: Mittwoch, 26. September 2018 18:49
> To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: [XS] RFR : 8211149: fix potential memleak in
> getJavaIDFromLangID after failing SetupI18nProps call [windows]
> 
> Hi Matthias,
> 
> Thank you for fixing this. Here are my comments:
> 
> - You could merge the similar for loop at 191-193, and place the loop at
> the very end before it returns.
> 
> - Please expand the if block body at line 196.
> 
> Naoto
> 
> On 9/26/18 7:29 AM, Baesken, Matthias wrote:
> > Hello,   could you please review this small change   (windows only)   ?
> >
> > Currently, the function   "getJavaIDFromLangID"    (located in windows
> java_props_md.c)
> > only does proper deallocations after a  successful call to the  function
> SetupI18nProps.  See
> >
> >      if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT),
> >                     &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]),
> &(elems[4]))) {
> >
> >     ......
> >          for (index = 0; index < 5; index++) {
> >              free(elems[index]);
> >          }
> >
> >
> > However a failing call (SetupI18nProps returning false) might still need
> deallocations,  because the function  SetupI18nProps can malloc memory in
> the failing case as well .
> > The change initializes   the   pointers  in  char * elems[5];
> > And later  frees them in case they are not NULL .
> >
> > Webrev and bug :
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webr
> ev/
> >
> > https://bugs.openjdk.java.net/browse/JDK-8211149
> >
> >
> > Best regards, Matthias
> >

From adinn at redhat.com  Thu Sep 27 14:55:30 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 27 Sep 2018 15:55:30 +0100
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <79485c16-207a-c2f3-d274-f64388b91658@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
 <8c2e04a9-fcc1-4d77-5a08-3ca136288c25@redhat.com>
 <79485c16-207a-c2f3-d274-f64388b91658@gmail.com>
Message-ID: <1ed27da8-882c-8547-cb0f-d5d730141c9e@redhat.com>

Hi Raffaello,

On 27/09/18 15:20, raffaello.giulietti at gmail.com wrote:
> Hi Andrew,
> On the other side, in April this year I submitted another quite fast and
> supposedly correct algorithm on this mailing list and I referred to an
> accompanying paper by myself that gives full explanations on that
> variant. Except for a couple of persons in private, nobody cared to send
> me any observation or comment, neither on the code nor on the paper.

I'm sorry I didn't see that post. I would have been very happy to review
the paper as well as the code. Unfortunately, none of us have time to
catch everything and we certainly don't always see every contribution.

> The present algorithm is superior. I have the theory in notes, in my
> head, on napkins, on paper sheets all over my desk and floors. But
> rather than spending time on the paper itself, like I did almost in vain
> for the April variant, I preferred investing it in coding, for several
> reasons:
> * Only code executes, not a paper.
> * Only code gives results that can be compared against.
> * Only code can give indications on performance enhancements.
> * Only code is interesting to be submitted to the OpenJDK.
> * Having a paper without having tried the ideas in code is half the fun
> and half as useful.

I think this only presents one side of the argument here. For code of
anything but the most basic complexity. Assuming that by paper you mean
anything that goes beyond executable statements, including comments,
list discussions and reviews like this one, design notes and documents,
specifications et al

Only a paper tells you what an executing piece of code is actually doing

Only paper tells you what the results produced by that code need to be
compared against to determine correctness, accuracy, etc

Only paper can tell you whether achieved performance is worse than or
better than can be expected (or where in between it lies)

Only paper can explain what OpenJDK is supposed to be doing, why and how
the specific elements of the implementation achieve that what/why i.e.
withouth that audit trail OpenJDK will be dead in the water in no time
at all

Having code without the paper to tell you what ideas it implements is no
fun and n use at all.

I think that last one exemplifies a key asymmetry that always needs to
be borne in mind. If your last contribution did not get any signifcant
review on this or some other list then I think we really messed up.

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 naoto.sato at oracle.com  Thu Sep 27 15:16:27 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 27 Sep 2018 08:16:27 -0700
Subject: [XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID
 after failing SetupI18nProps call [windows]
In-Reply-To: <VI1PR02MB4384FCE6999829B99C44A15293140@VI1PR02MB4384.eurprd02.prod.outlook.com>
References: <VI1PR02MB43842C138735904D7C1FEF3193150@VI1PR02MB4384.eurprd02.prod.outlook.com>
 <4f53658d-1014-03e9-f5cb-3d1c41ae246c@oracle.com>
 <VI1PR02MB4384FCE6999829B99C44A15293140@VI1PR02MB4384.eurprd02.prod.outlook.com>
Message-ID: <aef19b26-adf3-eb12-f97c-3f8040a81e2e@oracle.com>

Looks good. Please add a noreg-* label to the JIRA issue.

Naoto

On 9/27/18 7:42 AM, Baesken, Matthias wrote:
> Hi,  thanks for your comments, I posted a second webrev  :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.1/webrev/
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: naoto.sato at oracle.com <naoto.sato at oracle.com>
>> Sent: Mittwoch, 26. September 2018 18:49
>> To: Baesken, Matthias <matthias.baesken at sap.com>; core-libs-
>> dev at openjdk.java.net
>> Subject: Re: [XS] RFR : 8211149: fix potential memleak in
>> getJavaIDFromLangID after failing SetupI18nProps call [windows]
>>
>> Hi Matthias,
>>
>> Thank you for fixing this. Here are my comments:
>>
>> - You could merge the similar for loop at 191-193, and place the loop at
>> the very end before it returns.
>>
>> - Please expand the if block body at line 196.
>>
>> Naoto
>>
>> On 9/26/18 7:29 AM, Baesken, Matthias wrote:
>>> Hello,   could you please review this small change   (windows only)   ?
>>>
>>> Currently, the function   "getJavaIDFromLangID"    (located in windows
>> java_props_md.c)
>>> only does proper deallocations after a  successful call to the  function
>> SetupI18nProps.  See
>>>
>>>       if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT),
>>>                      &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]),
>> &(elems[4]))) {
>>>
>>>      ......
>>>           for (index = 0; index < 5; index++) {
>>>               free(elems[index]);
>>>           }
>>>
>>>
>>> However a failing call (SetupI18nProps returning false) might still need
>> deallocations,  because the function  SetupI18nProps can malloc memory in
>> the failing case as well .
>>> The change initializes   the   pointers  in  char * elems[5];
>>> And later  frees them in case they are not NULL .
>>>
>>> Webrev and bug :
>>>
>>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webr
>> ev/
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8211149
>>>
>>>
>>> Best regards, Matthias
>>>

From raffaello.giulietti at gmail.com  Thu Sep 27 15:23:01 2018
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 27 Sep 2018 17:23:01 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <1ed27da8-882c-8547-cb0f-d5d730141c9e@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <f10536c5-9eb3-b7bb-0157-5ed2e973f272@gmail.com>
 <8c2e04a9-fcc1-4d77-5a08-3ca136288c25@redhat.com>
 <79485c16-207a-c2f3-d274-f64388b91658@gmail.com>
 <1ed27da8-882c-8547-cb0f-d5d730141c9e@redhat.com>
Message-ID: <3cae85db-014a-d469-1744-2c290829e90c@gmail.com>

On 2018-09-27 16:55, Andrew Dinn wrote:
> Hi Raffaello,
> 
> On 27/09/18 15:20, raffaello.giulietti at gmail.com wrote:
>> Hi Andrew,
>> On the other side, in April this year I submitted another quite fast and
>> supposedly correct algorithm on this mailing list and I referred to an
>> accompanying paper by myself that gives full explanations on that
>> variant. Except for a couple of persons in private, nobody cared to send
>> me any observation or comment, neither on the code nor on the paper.
> 
> I'm sorry I didn't see that post. I would have been very happy to review
> the paper as well as the code. Unfortunately, none of us have time to
> catch everything and we certainly don't always see every contribution.
> 

I understand that most people are busy, so I was not really surprised 
not to get feedback on a rather tiny issue in the overall huge codebase.



>> The present algorithm is superior. I have the theory in notes, in my
>> head, on napkins, on paper sheets all over my desk and floors. But
>> rather than spending time on the paper itself, like I did almost in vain
>> for the April variant, I preferred investing it in coding, for several
>> reasons:
>> * Only code executes, not a paper.
>> * Only code gives results that can be compared against.
>> * Only code can give indications on performance enhancements.
>> * Only code is interesting to be submitted to the OpenJDK.
>> * Having a paper without having tried the ideas in code is half the fun
>> and half as useful.
> 
> I think this only presents one side of the argument here. For code of
> anything but the most basic complexity. Assuming that by paper you mean
> anything that goes beyond executable statements, including comments,
> list discussions and reviews like this one, design notes and documents,
> specifications et al
> 

My point is about priorities and the past experience with almost zero 
feedback on the former implementation, not that a paper isn't due or 
useless. On the contrary, I'm the first that would not trust my own code 
without an explanation.



> Only a paper tells you what an executing piece of code is actually doing
> 
> Only paper tells you what the results produced by that code need to be
> compared against to determine correctness, accuracy, etc
> 
> Only paper can tell you whether achieved performance is worse than or
> better than can be expected (or where in between it lies)
> 
> Only paper can explain what OpenJDK is supposed to be doing, why and how
> the specific elements of the implementation achieve that what/why i.e.
> withouth that audit trail OpenJDK will be dead in the water in no time
> at all
> 
> Having code without the paper to tell you what ideas it implements is no
> fun and n use at all.
> 

Why "no use at all"? That's unfair.

It might not be fun currently, but it is quite useful anyway in its 
present form, having produced, as of today, some 400 billions correct 
results in 1/13 of the time.



> I think that last one exemplifies a key asymmetry that always needs to
> be borne in mind. If your last contribution did not get any signifcant
> review on this or some other list then I think we really messed up.
> 

Except where noted above, I agree with these observations. Currently, 
however, I'm in the lucky position to have both the explanation and the 
code, so they don't apply for myself in this particular case.

I'm thinking on how to present the ideas in some sketchy form, just to 
share the fun and mathematically convince the inclined ones, before the 
paper is ready.



Greetings
Raffaello


From raffaello.giulietti at gmail.com  Thu Sep 27 15:37:13 2018
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 27 Sep 2018 17:37:13 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
Message-ID: <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>

Hi Ulf,


On 2018-09-27 16:40, Ulf Adams wrote:
> Hi Raffaello,
> 
> I am the author of a recent publication on double to string conversion 
> [1] - the Ryu algorithm. I've been aware of the problems with the Jdk 
> for several years, and am very much looking forward to improvements in 
> correctness and performance in this area.
> 

What a coincidence! I'm happy to hear that the quest for better 
floating->string conversions has not stopped. Tomorrow I'll download 
your paper and have a look at it during the weekend.



> I have done some testing against my Java implementation of the Ryu 
> algorithm described in the linked paper. Interestingly, I've found a few 
> cases where they output different results. In particular:
> 1.0E-323 is printed as 9.9E-324
> 1.0E-322 is printed as 9.9E-323

If Ryu also produces 1 digit long outputs, then your results above are 
correct. But then Ryu should also output 5.0E-324 rather than 4.9E-324, 
for example.
Even better, it should output 5E-324, 1E-323 and 1E-322 because adding 
the .0 part might confuse a human reader to believe that 2 digits are 
really needed. But then 4.9E-324, 9.9E-324 and 9.9E-323 are closer to 
the double.

2 digits are for backward compatibility with the existing spec which 
requires at least one digit to the right of the decimal point.


> 
> It's likely that there are more such cases - I only ran a sample of 
> double-precision numbers. Arguably, 9.9 is the correctly rounded 2-digit 
> output and Ryu is incorrect here. That's what you get when you have a 
> special case for Java without a correctness proof. :-(
> 
> In terms of performance, this algorithm performs almost exactly the same 
> as my Java implementation of Ryu, although I'd like to point out that my 
> C implementation of Ryu is quite a bit faster (though note that it 
> generates different output, in particular, it only outputs a single 
> digit of precision in the above cases, rather than two), and I didn't 
> backport all the performance improvements from the Java version, yet. It 
> looks like this is not coincidence - as far as I can see so far, it's 
> algorithmically very similar, although it manages to avoid the loop I'm 
> using in Ryu to find the shortest representation.
> 
> I have a few comments:
> 
>  ? ? ?*? ? ?<li> It rounds to {@code v} according to the usual 
> round-to-closest
>  ? ? ?*? ? ?rule of IEEE 754 floating-point arithmetic.
> - Since you're spelling out the rounding rules just below, this is 
> duplicated, and by itself, it's unclear since it doesn't specify the 
> specific sub-type (round half even).
> 

I tried to save as much of the original spec wording as possible. 
Perhaps it isn't worthwhile.



> - Naming: I'd strongly suggest to use variable names that relate to 
> what's stored, e.g., m for mantissa, e for exponent, etc.
> 

I currently prefer to be consistent with a forthcoming paper of mine on 
the subject. But thanks for the suggestion.



> - What's not clear to me is how the algorithm determines how many digits 
> to print.
> 

You'll have to wait for the paper.


> - Also, it might be nicer to move the long multiplications to a helper 
> method - at least from a short look, it looks like the computations of 
> vn, vnl, and vnr are identical.
> 

I tried several variants: the current one seems to be the faster with 
the current optimizations of C2. Some day I'll also try with Graal.



> - I looked through the spec, and it looks like all cases are 
> well-defined. Yay!
> 
> I will need some more time to do a more thorough review of the code and 
> more testing for differences. Unfortunately, I'm also traveling the next 
> two weeks, so this might take a bit of time.
> 

I thank you in advance for your willingness to review the code but my 
understanding is that only the officially appointed reviewers can 
approve OpenJDK contributions, which is of course a good policy. 
Besides, as two Andrews engineers from RedHat correctly observe, 
understanding the rationale of the code without the planned accompanying 
paper is hard.



> I'm not a contributor to the Jdk, and this isn't my full-time job. I was 
> lurking here because I was going to send a patch for the double to 
> string conversion code myself (based on Ryu).
> 

All my efforts on this projects are done in my unpaid spare time, too.


> Thanks,
> 
> -- Ulf
> 
 > [1] https://dl.acm.org/citation.cfm?id=3192369
 > [2] https://github.com/google/double-conversion
 > [3] https://en.wikipedia.org/wiki/Rounding
 >


Thank you
Raffaello







From adinn at redhat.com  Thu Sep 27 15:53:24 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 27 Sep 2018 16:53:24 +0100
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
 <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>
Message-ID: <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com>

On 27/09/18 16:37, Raffaello Giulietti wrote:
  . . .
> I thank you in advance for your willingness to review the code but my
> understanding is that only the officially appointed reviewers can
> approve OpenJDK contributions, which is of course a good policy.
> Besides, as two Andrews engineers from RedHat correctly observe,
> understanding the rationale of the code without the planned accompanying
> paper is hard.

Oh no, let me stop you right there! Anyone competent can offer a review
(well incompetent people can too but let's assume they get ignored :-).
Indeed, an expert critique is always very welcome and reviewers normally
get credited even if they have no official status. The official
reviewers are needed for a final say so. No one sensible is going to
reject clear and clearly justified advice.

>> I'm not a contributor to the Jdk, and this isn't my full-time job. I
>> was lurking here because I was going to send a patch for the double to
>> string conversion code myself (based on Ryu).
>>
> 
> All my efforts on this projects are done in my unpaid spare time, too.
Which is very much appreciated, thank you.

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 raffaello.giulietti at gmail.com  Thu Sep 27 16:00:56 2018
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 27 Sep 2018 18:00:56 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
 <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>
 <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com>
Message-ID: <2181f074-15b8-ed37-2f64-b675249216ac@gmail.com>

On 2018-09-27 17:53, Andrew Dinn wrote:
> On 27/09/18 16:37, Raffaello Giulietti wrote:
>    . . .
>> I thank you in advance for your willingness to review the code but my
>> understanding is that only the officially appointed reviewers can
>> approve OpenJDK contributions, which is of course a good policy.
>> Besides, as two Andrews engineers from RedHat correctly observe,
>> understanding the rationale of the code without the planned accompanying
>> paper is hard.
> 
> Oh no, let me stop you right there! Anyone competent can offer a review
> (well incompetent people can too but let's assume they get ignored :-).
> Indeed, an expert critique is always very welcome and reviewers normally
> get credited even if they have no official status. The official
> reviewers are needed for a final say so. No one sensible is going to
> reject clear and clearly justified advice.
> 

An excellent policy, indeed!



>>> I'm not a contributor to the Jdk, and this isn't my full-time job. I
>>> was lurking here because I was going to send a patch for the double to
>>> string conversion code myself (based on Ryu).
>>>
>>
>> All my efforts on this projects are done in my unpaid spare time, too.
> Which is very much appreciated, thank you.
> 

Thank all of you for your interest in this issue.


Greetings
Raffaello

From henry.jen at oracle.com  Thu Sep 27 16:49:52 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 27 Sep 2018 09:49:52 -0700
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
Message-ID: <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>

Agree, please find updated webrev[1].

[1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/

Cheers,
Henry


> On Sep 27, 2018, at 1:45 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 27/09/2018 03:58, Henry Jen wrote:
>> Hi,
>> 
>> Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.
>> 
>> I had reviewed the change and tested, but we need a ?R?eviewer.
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8210810
>> 
>> 
> The change to args.c looks okay but for the test then I assume it would be better to just add another test case to the existing ArgFileSyntax.java.
> 
> -Alan


From brian.burkhalter at oracle.com  Thu Sep 27 19:10:44 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 27 Sep 2018 12:10:44 -0700
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <2181f074-15b8-ed37-2f64-b675249216ac@gmail.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
 <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>
 <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com>
 <2181f074-15b8-ed37-2f64-b675249216ac@gmail.com>
Message-ID: <C5D73548-C985-4630-AE31-49762F17E8FC@oracle.com>

On Sep 27, 2018, at 9:00 AM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:

> On 2018-09-27 17:53, Andrew Dinn wrote:
>> On 27/09/18 16:37, Raffaello Giulietti wrote:
>>   . . .
>>> I thank you in advance for your willingness to review the code but my
>>> understanding is that only the officially appointed reviewers can
>>> approve OpenJDK contributions, which is of course a good policy.
>>> Besides, as two Andrews engineers from RedHat correctly observe,
>>> understanding the rationale of the code without the planned accompanying
>>> paper is hard.
>> Oh no, let me stop you right there! Anyone competent can offer a review
>> (well incompetent people can too but let's assume they get ignored :-).
>> Indeed, an expert critique is always very welcome and reviewers normally
>> get credited even if they have no official status. The official
>> reviewers are needed for a final say so. No one sensible is going to
>> reject clear and clearly justified advice.
> 
> An excellent policy, indeed!

I was going to reply with essentially the same comments. While an imprimatur from at least one sanctioned OpenJDK reviewer is required eventually, comments and review from any competent parties are most welcome. This is especially the case for a relatively complicated topic such as the one of this thread.

>>>> I'm not a contributor to the Jdk, and this isn't my full-time job. I
>>>> was lurking here because I was going to send a patch for the double to
>>>> string conversion code myself (based on Ryu).
>>>> 
>>> 
>>> All my efforts on this projects are done in my unpaid spare time, too.
>> Which is very much appreciated, thank you.
> 
> Thank all of you for your interest in this issue.

I would like to second that. It is great to see so many comments on this topic and to have knowledgable people paying attention.

Brian

From Roger.Riggs at oracle.com  Thu Sep 27 19:21:00 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 27 Sep 2018 15:21:00 -0400
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
 <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
Message-ID: <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>

Hi Pallavi,

I'd suggest using @link for the reference (in both files).
It will be easier for the reader to traverse and understand the pattern.

DateTimeFormatterBuilder.java: line 836.
The trailing "</p>" should be omitted so the readability of the source 
is maintained.

Otherwise, looks good,

Thanks, Roger



On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
> In DateTimeFormatter you need to qualify the @code part to refer to
> DateTimeFormatterBuilder.
> Otherwise good.
> thanks
> Stephen
>
>
> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>> Thanks for the clarification. Here is the updated webrev for review :
>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>>
>> Thanks,
>> Pallavi Sonal
>>
>> -----Original Message-----
>> From: Stephen Colebourne <scolebourne at joda.org>
>> Sent: Tuesday, September 25, 2018 4:39 PM
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>>
>> I think it makes sense for both, although I was only considering
>> appendInstant() when I wrote it.
>> Stephen
>>
>>
>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>> Hi Stephen,
>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne <scolebourne at joda.org>
>>> Sent: Sunday, September 23, 2018 12:36 PM
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>>> handle offsets
>>>
>>> Thanks
>>>
>>> Can we change the docs to:
>>>
>>> <p>
>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>>>
>>> thanks
>>> Stephen
>>>
>>>
>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>>>>    http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>>>
>>>> Thanks,
>>>> Pallavi Sonal.
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>> Sent: Thursday, September 20, 2018 6:38 PM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>>>> handle offsets
>>>>
>>>> Thanks for the update.
>>>>
>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
>>>> eg. a negative offset at MAX or a positive offset at MIN.
>>>>
>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>>>> Here is the updated webrev for review :
>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Pallavi Sonal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>> Sent: Thursday, September 20, 2018 2:50 AM
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>> should handle offsets
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> The proposed fix does not tackle the bug fully. The bug is that
>>>>> the spec says
>>>>>
>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>>>>>
>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>>>>>
>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>>>>>
>>>>> Furthermore, although there are numerous valid ISO-8601 ways of
>>>>> saying zero, this format uses dashes and colons in the date/time
>>>>> part, so
>>>>> ISO-8601 restricts the offset to only those formats that include colons.
>>>>>
>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the changes to the following issue:
>>>>>>
>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>>>>>>
>>>>>>
>>>>>>
>>>>>> The proposed fix is located at:
>>>>>>
>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>>>>>>
>>>>>>
>>>>>>
>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Pallavi Sonal
>>>>>>
>>>>>>
>>>>>>
>>>>>>

-- 
Thanks, Roger


From amaembo at gmail.com  Fri Sep 28 04:51:50 2018
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 28 Sep 2018 11:51:50 +0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java
In-Reply-To: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>
References: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
 <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>
Message-ID: <CAE+3fjZpssja+6a5nsvdZerr34R-ow7U2VQNnCCCyAFR+9OW1A@mail.gmail.com>

Hello!

I can volunteer doing this if OpenJDK community is really interested.
I've launched the inspection over all java.* and jdk.* modules and
found 4064 warnings.
As an example, I converted all C-style array declarations in java.base
module (660 warnings in 168 files). Here's the webrev:
http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/

To me it's easier to review the whole patch rather than click on every file:
http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/jdk.patch

I checked the result by eyes thoroughly and did not find anything
wrong. So if you're interested I can prepare a patch which covers any
full JDK sources or any subset of it.
The only questions are which subset should be processed and should I
also update copyrights for changed files (doing this automatically
could be more risky unless there's
already well-tested utility to do this).

With best regards,
Tagir Valeev.


On Thu, Sep 13, 2018 at 8:02 AM Stuart Marks <stuart.marks at oracle.com> wrote:
>
> Cool, I didn't know that IntelliJ IDEA has such an inspection, but I'm not
> surprised.
>
> Perhaps a volunteer can run this inspection over parts of the JDK code base and
> see what comes up, and possibly propose some patches. :-)
>
> s'marks
>
>
> On 9/11/18 10:34 PM, Tomasz Linkowski wrote:
> > Hello Stuart,
> >
> > I'm not sure whether you're aware that IntelliJ IDEA has an automatic
> > inspection named "C-style array declaration":
> > - description:
> > https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/src/inspectionDescriptions/CStyleArrayDeclaration.html
> > - logic:
> > https://github.com/JetBrains/intellij-community/blob/master/plugins/InspectionGadgets/InspectionGadgetsAnalysis/src/com/siyeh/ig/style/CStyleArrayDeclarationInspection.java
> >
> > You can run such single inspection over the entire project as described here:
> > https://www.jetbrains.com/help/idea/running-inspection-by-name.html
> >
> > It will fix all such C-style array declarations for you automatically.
> >
> > --
> > Regards,
> > Tomasz Linkowski
> >
> >
> >     From: Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>>
> >     To: "ullenboom at gmail.com <mailto:ullenboom at gmail.com>"
> >     <ullenboom at gmail.com <mailto:ullenboom at gmail.com>>
> >     Cc: "core-libs-dev at openjdk.java.net
> >     <mailto:core-libs-dev at openjdk.java.net>" <core-libs-dev at openjdk.java.net
> >     <mailto:core-libs-dev at openjdk.java.net>>
> >     Bcc:
> >     Date: Tue, 11 Sep 2018 13:23:41 -0700
> >     Subject: Re: ByteArrayOutputStream should not have a new writeBytes method
> >     in Java 11
> >
> >     2. even if, it should not be byte b[] but byte[] b
> >
> >
> >     Yeah we need to clean occurrences of this anachronistic array declaration
> >     from the JDK. I noticed a few others nearby. It's startling that a new
> >     occurrence has crept it. (Or maybe not, perhaps it was done to conform to
> >     the nearby code.)
> >
> >
> >     Any volunteers to clean this up?
> >
> >
> >     An interesting exercise would be to write a detector for this declaration
> >     style.
> >
> >
> >     s'marks
> >
>

From stuart.marks at oracle.com  Fri Sep 28 05:51:45 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 27 Sep 2018 22:51:45 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <65f5660a-807b-426a-7af5-d5f95a6089ba@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
Message-ID: <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>

Hi Andrew,

Let me first stay that this issue of "ByteBuffer might not be the right answer" 
is something of a digression from the JEP discussion. I think the JEP should 
proceed forward using MBB with the API that you and Alan had discussed 
previously. At most, the discussion of the "right thing" issue might affect a 
side note in the JEP text about possible limitations and future directions of 
this effort. However, it's not a blocker to the JEP making progress as far as 
I'm concerned.

With that in mind, I'll discuss the issue of multithreaded access to ByteBuffers 
and how this bears on whether buffers are or aren't the "right answer." There 
are actually several issues that figure into the "right answer" analysis. In 
this message, though, I'll just focus on the issue of multithreaded access.

To recap (possibly for the benefit of other readers) the Buffer class doc has 
the following statement:

     Buffers are not safe for use by multiple concurrent threads. If a buffer
     is to be used by more than one thread then access to the buffer should be
     controlled by appropriate synchronization.

Buffers are primarily designed for sequential operations such as I/O or codeset 
conversion. Typical buffer operations set the mark, position, and limit before 
initiating the operation. If the operation completes partially -- not uncommon 
with I/O or codeset conversion -- the position is updated so that the operation 
can be resumed easily from where it left off.

The fact that buffers not only contain the data being operated upon but also 
mutable state information such as mark/position/limit makes it difficult to have 
multiple threads operate on different parts of the same buffer. Each thread 
would have to lock around setting the position and limit and performing the 
operation, preventing any parallelism. The typical way to deal with this is to 
create multiple buffer slices, one per thread. Each slice has its own 
mark/position/limit values but shares the same backing data.

We can avoid the need for this by adding absolute bulk operations, right?

Let's suppose we were to add something like this (considering ByteBuffer only, 
setting the buffer views aside):

     get(int srcOff, byte[] dst, int dstOff, int length)
     put(int dstOff, byte[] src, int srcOff, int length)

Each thread can perform its operations on a different part of the buffer, in 
parallel, without interference from the others. Presumably these operations 
don't read or write the mark and position. Oh, wait. The existing absolute put 
and get overloads *do* respect the buffer's limit, so the absolute bulk 
operations ought to as well. This means they do depend on shared state. (I guess 
we could make the absolute bulk ops not respect the limit, but that seems 
inconsistent.)

OK, let's adopt an approach similar to what was described by Peter Levart a 
couple messages upthread, where a) there is an initialization step where various 
things including the limit are set properly; b) the buffer is published to the 
worker threads properly, e.g., using a lock or other suitable memory operation; 
and c) all worker threads agree only to use absolute operations and to avoid 
relative operations.

Now suppose the threads have completed their work and you want to, say, write 
the buffer's contents to a channel. You have to carefully make sure the threads 
are all finished and properly publish their results back to some central thread, 
have that central thread receive the results, set the position and limit, after 
which the central thread can initiate the I/O operation.

This can certainly be made to work.

But note what we just did. We now have an API where:

  - there are different "phases", where in one phase all the methods work, but 
in another phase only certain methods work (otherwise it breaks silently);

  - you have to carefully control all the code to ensure that the wrong methods 
aren't called when the buffer is in the wrong phase (otherwise it breaks 
silently); and

  - you can't hand off the buffer to a library (3rd party or JDK) without 
carefully orchestrating a transition into the right phase (otherwise it breaks 
silently).

Frankly, this is pretty crappy. It's certainly possible to work around it. 
People do, and it is painful, and they complain about it up and down all day 
long (and rightfully so).

Note that this discussion is based primarily on looking at the ByteBuffer API. I 
have not done extensive investigation of the impact of the various buffer views 
(IntBuffer, LongBuffer, etc.), nor have I looked thoroughly at the 
implementations. I have no doubt that we will run into additional issues when we 
do those investigations.

If we were designing an API to support multi-threaded access to memory regions, 
it would almost certainly look nothing like the buffer API. This is what Alan 
means by "buffers might not be the right answer." As things stand, it appears 
quite difficult to me to fix the multi-threaded access problem without turning 
buffers into something they aren't, or fragmenting the API in some complex and 
uncomfortable way.

Finally, note that this is not an argument against adding bulk absolute 
operations! I think we should probably go ahead and do that anyway. But let's 
not fool ourselves into thinking that bulk absolute operations solve the 
multi-threaded buffer access problem.

s'marks


From zhangbodut at gmail.com  Fri Sep 28 06:06:47 2018
From: zhangbodut at gmail.com (Bo Zhang)
Date: Fri, 28 Sep 2018 14:06:47 +0800
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
 <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
Message-ID: <8ADC77BE-689F-4876-904C-8B46F7226C64@gmail.com>

Thanks Henry, this change looks good to me. I assume this patch will be backported to 11GA, will it be back ported to 10 as well?

Regards,
Bo

> On 28 Sep 2018, at 00:49, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Agree, please find updated webrev[1].
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
> 
> Cheers,
> Henry
> 
> 
>> On Sep 27, 2018, at 1:45 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 27/09/2018 03:58, Henry Jen wrote:
>>> Hi,
>>> 
>>> Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.
>>> 
>>> I had reviewed the change and tested, but we need a ?R?eviewer.
>>> 
>>> Cheers,
>>> Henry
>>> 
>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8210810
>>> 
>>> 
>> The change to args.c looks okay but for the test then I assume it would be better to just add another test case to the existing ArgFileSyntax.java.
>> 
>> -Alan
> 


From peter.levart at gmail.com  Fri Sep 28 07:21:13 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 28 Sep 2018 09:21:13 +0200
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
Message-ID: <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.com>

Hi Stuart,

I mostly agree with your assessment about the suitability of the 
ByteBuffer API for nice multithreaded use. What would such API look 
like? I think pretty much like ByteBuffer but without things that mutate 
mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore. 
That would be in my opinion the most low-level API possible. If you add 
things to such API that coordinate multithreaded access to the 
underlying memory, you are already creating a concurrent data structure 
for a particular set of use cases, which might not cover all possible 
use cases or be sub-optimal at some of them. So I think this is better 
layered on top of such API not built into it. Low-level multithreaded 
access to memory is, in my opinion, always going to be "unsafe" from the 
standpoint of coordination. It's not only the 
mark/position/limit/ByteOrder that is not multithreaded-friendly about 
ByteBuffer API, but the underlying memory too. It would be nice if 
mark/position/limit/ByteOrder weren't in the way though.

Regards, Peter

On 09/28/2018 07:51 AM, Stuart Marks wrote:
> Hi Andrew,
>
> Let me first stay that this issue of "ByteBuffer might not be the 
> right answer" is something of a digression from the JEP discussion. I 
> think the JEP should proceed forward using MBB with the API that you 
> and Alan had discussed previously. At most, the discussion of the 
> "right thing" issue might affect a side note in the JEP text about 
> possible limitations and future directions of this effort. However, 
> it's not a blocker to the JEP making progress as far as I'm concerned.
>
> With that in mind, I'll discuss the issue of multithreaded access to 
> ByteBuffers and how this bears on whether buffers are or aren't the 
> "right answer." There are actually several issues that figure into the 
> "right answer" analysis. In this message, though, I'll just focus on 
> the issue of multithreaded access.
>
> To recap (possibly for the benefit of other readers) the Buffer class 
> doc has the following statement:
>
> ??? Buffers are not safe for use by multiple concurrent threads. If a 
> buffer
> ??? is to be used by more than one thread then access to the buffer 
> should be
> ??? controlled by appropriate synchronization.
>
> Buffers are primarily designed for sequential operations such as I/O 
> or codeset conversion. Typical buffer operations set the mark, 
> position, and limit before initiating the operation. If the operation 
> completes partially -- not uncommon with I/O or codeset conversion -- 
> the position is updated so that the operation can be resumed easily 
> from where it left off.
>
> The fact that buffers not only contain the data being operated upon 
> but also mutable state information such as mark/position/limit makes 
> it difficult to have multiple threads operate on different parts of 
> the same buffer. Each thread would have to lock around setting the 
> position and limit and performing the operation, preventing any 
> parallelism. The typical way to deal with this is to create multiple 
> buffer slices, one per thread. Each slice has its own 
> mark/position/limit values but shares the same backing data.
>
> We can avoid the need for this by adding absolute bulk operations, right?
>
> Let's suppose we were to add something like this (considering 
> ByteBuffer only, setting the buffer views aside):
>
> ??? get(int srcOff, byte[] dst, int dstOff, int length)
> ??? put(int dstOff, byte[] src, int srcOff, int length)
>
> Each thread can perform its operations on a different part of the 
> buffer, in parallel, without interference from the others. Presumably 
> these operations don't read or write the mark and position. Oh, wait. 
> The existing absolute put and get overloads *do* respect the buffer's 
> limit, so the absolute bulk operations ought to as well. This means 
> they do depend on shared state. (I guess we could make the absolute 
> bulk ops not respect the limit, but that seems inconsistent.)
>
> OK, let's adopt an approach similar to what was described by Peter 
> Levart a couple messages upthread, where a) there is an initialization 
> step where various things including the limit are set properly; b) the 
> buffer is published to the worker threads properly, e.g., using a lock 
> or other suitable memory operation; and c) all worker threads agree 
> only to use absolute operations and to avoid relative operations.
>
> Now suppose the threads have completed their work and you want to, 
> say, write the buffer's contents to a channel. You have to carefully 
> make sure the threads are all finished and properly publish their 
> results back to some central thread, have that central thread receive 
> the results, set the position and limit, after which the central 
> thread can initiate the I/O operation.
>
> This can certainly be made to work.
>
> But note what we just did. We now have an API where:
>
> ?- there are different "phases", where in one phase all the methods 
> work, but in another phase only certain methods work (otherwise it 
> breaks silently);
>
> ?- you have to carefully control all the code to ensure that the wrong 
> methods aren't called when the buffer is in the wrong phase (otherwise 
> it breaks silently); and
>
> ?- you can't hand off the buffer to a library (3rd party or JDK) 
> without carefully orchestrating a transition into the right phase 
> (otherwise it breaks silently).
>
> Frankly, this is pretty crappy. It's certainly possible to work around 
> it. People do, and it is painful, and they complain about it up and 
> down all day long (and rightfully so).
>
> Note that this discussion is based primarily on looking at the 
> ByteBuffer API. I have not done extensive investigation of the impact 
> of the various buffer views (IntBuffer, LongBuffer, etc.), nor have I 
> looked thoroughly at the implementations. I have no doubt that we will 
> run into additional issues when we do those investigations.
>
> If we were designing an API to support multi-threaded access to memory 
> regions, it would almost certainly look nothing like the buffer API. 
> This is what Alan means by "buffers might not be the right answer." As 
> things stand, it appears quite difficult to me to fix the 
> multi-threaded access problem without turning buffers into something 
> they aren't, or fragmenting the API in some complex and uncomfortable 
> way.
>
> Finally, note that this is not an argument against adding bulk 
> absolute operations! I think we should probably go ahead and do that 
> anyway. But let's not fool ourselves into thinking that bulk absolute 
> operations solve the multi-threaded buffer access problem.
>
> s'marks
>


From takiguc at linux.vnet.ibm.com  Fri Sep 28 07:28:06 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 28 Sep 2018 16:28:06 +0900
Subject: How can I solve Modularity related issue ?
Message-ID: <ef23405648c061fd2db7359c1fa160f1@linux.vnet.ibm.com>

Hello.

One of JDBC application with JavaDB did not work on JDK12.
Following exception happened:
? java.sql.SQLException: No suitable driver found for jdbc:derby:xxxxxx

I assume, this issue related Modularity feature...
I could not solve this issue by myself.

In order to investigate the root cause, I would appreciate telling me 
how to identify the problem and debug it.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

===========================
The detail instruction is as follows:
It has two types of SELECT statement call.
1. Use DriverManager
2. Use createJdbcRowSet()

"1" worked fine, "2" did not work on JDK11.
Same one worked fine on JDK8.

System / OS: RHEL 7.5 x86_64

Steps to Reproduce
1. Store JavaDB (derby.jar) in derby/lib/derby.jar
You can download Apache Derby (derby.jar) [1] or use JDK8's one

2. Download testcases [2][3][4], then compile and run following command
$ javac? SetupJavaDB.java JdbcRowSetProvider.java 
JdbcRowSetProviderA.java

3. Create DB
$ java -cp derby/lib/derby.jar:. SetupJavaDB

4. Run testcases
### Use DriverManager and createJdbcRowSet() ###
$ java -cp derby/lib/derby.jar:. JdbcRowSetProvider
### Use createJdbcRowSet() ###
$ java -cp derby/lib/derby.jar:. JdbcRowSetProviderA

On JDK8
$ ~/jdk8_181/jdk1.8.0_181/jre/bin/java -showversion -cp 
derby/lib/derby.jar:. JdbcRowSetProvider
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

1,One
2,Two
3,Three
1,One
2,Two
3,Three
$ ~/jdk8_181/jdk1.8.0_181/jre/bin/java -showversion -cp 
derby/lib/derby.jar:. JdbcRowSetProviderA
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

1,One
2,Two
3,Three

On JDK12
$ ~/jdk-12+12/bin/java -showversion -cp derby/lib/derby.jar:. 
JdbcRowSetProvider
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+12)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+12, mixed mode)
1,One
2,Two
3,Three
Exception in thread "main" java.sql.SQLException: No suitable driver 
found for jdbc:derby:javadb/db
??????? at 
java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702)
??????? at 
java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.connect(JdbcRowSetImpl.java:643)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.prepare(JdbcRowSetImpl.java:654)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.execute(JdbcRowSetImpl.java:556)
??????? at JdbcRowSetProvider.main(JdbcRowSetProvider.java:30)
$ ~/jdk-12+12/bin/java -showversion -cp derby/lib/derby.jar:. 
JdbcRowSetProviderA
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+12)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+12, mixed mode)
Exception in thread "main" java.sql.SQLException: No suitable driver 
found for jdbc:derby:javadb/db
??????? at 
java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702)
??????? at 
java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.connect(JdbcRowSetImpl.java:643)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.prepare(JdbcRowSetImpl.java:654)
??????? at 
java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.execute(JdbcRowSetImpl.java:556)
??????? at JdbcRowSetProviderA.main(JdbcRowSetProviderA.java:18)
===========================

[1] https://db.apache.org/derby/derby_downloads.html
[2] https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/SetupJavaDB.java
[3] 
https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/JdbcRowSetProvider.java
[4] 
https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/JdbcRowSetProviderA.java


From Alan.Bateman at oracle.com  Fri Sep 28 08:59:39 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Sep 2018 09:59:39 +0100
Subject: How can I solve Modularity related issue ?
In-Reply-To: <ef23405648c061fd2db7359c1fa160f1@linux.vnet.ibm.com>
References: <ef23405648c061fd2db7359c1fa160f1@linux.vnet.ibm.com>
Message-ID: <8632f274-3567-6121-5a60-cf626f8d5c3c@oracle.com>

On 28/09/2018 08:28, Ichiroh Takiguchi wrote:
> Hello.
>
> One of JDBC application with JavaDB did not work on JDK12.
> Following exception happened:
> ? java.sql.SQLException: No suitable driver found for jdbc:derby:xxxxxx
>
> I assume, this issue related Modularity feature...
> I could not solve this issue by myself.
I suspect this is related to the de-privileging of the java.sql.rowset 
module in JDK 9. The java.sql.rowset module is mapped to the platform 
class loader whereas historically the types in this module were defined 
by the boot class loader. This is relevant because java.sql.rowset is 
making use of the java.sql.DriverManager (in the java.sql module) and 
DriverManager is caller sensitive so it sees the caller coming from 
java.sql.rowset. This is problematic because the JDBC driver is on the 
class path and is not visible to the caller's class loader. The 
visibility check has always been in JDBC and I suspect this usage in the 
JDBC Rowset implementation only worked by accident in the past because 
DriverManager used the TCCL when called from code defined to the 
bootstrap class loader. I'm sure Lance will jump in but all previous 
investigations into changing behavior going back 20+ has come to nothing 
due to compatibility concerns.

-Alan.

From adinn at redhat.com  Fri Sep 28 09:16:13 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 28 Sep 2018 10:16:13 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
Message-ID: <2cdc5a22-0217-b985-9069-0fc72058f081@redhat.com>

Hi Stuart,

On 28/09/18 06:51, Stuart Marks wrote:
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think
> the JEP should proceed forward using MBB with the API that you and Alan
> had discussed previously. At most, the discussion of the "right thing"
> issue might affect a side note in the JEP text about possible
> limitations and future directions of this effort. However, it's not a
> blocker to the JEP making progress as far as I'm concerned.

Thanks for clarifying that point. I have already added a note to that
effect to the JEP. I take your other point that these limitations make
this JEP a less useful addition than it could be. However, it's hard to
see what else might usefully be provided that does not involve a
reworking of JDK core-lib (and, potentially, JVM) functionality that has
a much larger scope than is needed to crack the specific nut the JEP
addresses.

> With that in mind, I'll discuss the issue of multithreaded access to
> ByteBuffers and how this bears on whether buffers are or aren't the
> "right answer." There are actually several issues that figure into the
> "right answer" analysis. In this message, though, I'll just focus on the
> issue of multithreaded access.

Thank you for a very clear and interesting summary of the limitations of
the Buffer API. I have cut it from this reply for the sake of brevity
but I will respond to a few points.

I think the limitations you point out regarding concurrent clients' mode
of operation are less severe in this specific case because there is not
really a need for those client threads to reach a rendezvous point in
order to execute some form of FileChannel update. The buffer content is
persistent memory. So, essentially, the data writes constitute the update.

If independent threads can arrange to coordinate over carving up
separate regions of a persistent mapped buffer for parallel update then
they can also write and flush (by which I mean force cache writeback
for) those regions independently.

Clearly there will also be a need for threads to write common index
regions of the persistent mapped buffer in order to ensure that the
associated data updates are committed. That means the writes and flushes
for those common regions need to synchronize. However, that is simply
business as usual for persistent data management code. A TX manager will
already have code in place for this purpose, for example. Certainly,
that synchronized update will not need to rely on buffer cursor
(position) management.

Also, I am not sure I see any problem arising from your point about
absolute puts (and gets) depending on the 'limit' property. The various
put operations do indeed /read/ the current limit but they do not update
it. So, you are right to state that a persistent store management
library built over this API would need to ensure that put operations
were reined in via some form of rendezvous if it ever wanted to adjust
the limit. However, I don't think that is going to happen with a librray
that manages a mapped persistent store. I would expect that any such
code is never going to call clear(), flip(), truncate() -- nor make a
direct call to limit() --  except as part of the initialization or
reconciliation performed at startup before concurrent clients are unleashed.

Anyway, thank you for a clear warning as to the precise perils faced in
implementing correct client libraries over the base layer this JEP proposes.

> If we were designing an API to support multi-threaded access to memory
> regions, it would almost certainly look nothing like the buffer API.
> This is what Alan means by "buffers might not be the right answer." As
> things stand, it appears quite difficult to me to fix the multi-threaded
> access problem without turning buffers into something they aren't, or
> fragmenting the API in some complex and uncomfortable way.

Agreed.

> Finally, note that this is not an argument against adding bulk absolute
> operations! I think we should probably go ahead and do that anyway. But
> let's not fool ourselves into thinking that bulk absolute operations
> solve the multi-threaded buffer access problem.
Also agreed.

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  Fri Sep 28 10:23:18 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Sep 2018 11:23:18 +0100
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
 <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
Message-ID: <77ab8e11-6581-8b73-ad2d-782c0f4d28d7@oracle.com>



On 27/09/2018 17:49, Henry Jen wrote:
> Agree, please find updated webrev[1].
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
>
>
This looks okay to me, you may want to consider adding 8210810 to the 
@bug tag before pushing.

-Alan

From Alan.Bateman at oracle.com  Fri Sep 28 11:13:44 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Sep 2018 12:13:44 +0100
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java
In-Reply-To: <CAE+3fjZpssja+6a5nsvdZerr34R-ow7U2VQNnCCCyAFR+9OW1A@mail.gmail.com>
References: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
 <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>
 <CAE+3fjZpssja+6a5nsvdZerr34R-ow7U2VQNnCCCyAFR+9OW1A@mail.gmail.com>
Message-ID: <a85eaf4e-fb4f-5bc2-00d7-061d8b99b41f@oracle.com>

On 28/09/2018 05:51, Tagir Valeev wrote:
> Hello!
>
> I can volunteer doing this if OpenJDK community is really interested.
> I've launched the inspection over all java.* and jdk.* modules and
> found 4064 warnings.
> As an example, I converted all C-style array declarations in java.base
> module (660 warnings in 168 files). Here's the webrev:
> http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/
>
> To me it's easier to review the whole patch rather than click on every file:
> http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/jdk.patch
>
> I checked the result by eyes thoroughly and did not find anything
> wrong. So if you're interested I can prepare a patch which covers any
> full JDK sources or any subset of it.
> The only questions are which subset should be processed and should I
> also update copyrights for changed files (doing this automatically
> could be more risky unless there's
> already well-tested utility to do this).
>
Good to see this. Updating the copyright dates is annoying but if you 
can do that then it would be good. There is a script to do a bulk update 
that I think is better for cases like this but it doesn't seem to be run 
very often these days.

As regards doing the entire source base then I think that would be good. 
Due to the complexity of testing, changes to the java.desktop module are 
pushed to jdk/client repo rather than jdk/jdk so if it's not too awkward 
then it might be helper if the patch for java.desktop were a separate 
change that gets pushed to jdk/client rather than jdk/jdk.

-Alan

From pallavi.sonal at oracle.com  Fri Sep 28 12:35:21 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Fri, 28 Sep 2018 05:35:21 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
 <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
 <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>
Message-ID: <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default>

Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/

Thanks,
Pallavi Sonal

-----Original Message-----
From: Roger Riggs 
Sent: Friday, September 28, 2018 12:51 AM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Hi Pallavi,

I'd suggest using @link for the reference (in both files).
It will be easier for the reader to traverse and understand the pattern.

DateTimeFormatterBuilder.java: line 836.
The trailing "</p>" should be omitted so the readability of the source is maintained.

Otherwise, looks good,

Thanks, Roger



On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
> In DateTimeFormatter you need to qualify the @code part to refer to 
> DateTimeFormatterBuilder.
> Otherwise good.
> thanks
> Stephen
>
>
> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>> Thanks for the clarification. Here is the updated webrev for review :
>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>>
>> Thanks,
>> Pallavi Sonal
>>
>> -----Original Message-----
>> From: Stephen Colebourne <scolebourne at joda.org>
>> Sent: Tuesday, September 25, 2018 4:39 PM
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
>> handle offsets
>>
>> I think it makes sense for both, although I was only considering
>> appendInstant() when I wrote it.
>> Stephen
>>
>>
>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>> Hi Stephen,
>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne <scolebourne at joda.org>
>>> Sent: Sunday, September 23, 2018 12:36 PM
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
>>> handle offsets
>>>
>>> Thanks
>>>
>>> Can we change the docs to:
>>>
>>> <p>
>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>>>
>>> thanks
>>> Stephen
>>>
>>>
>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>>>>    http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>>>
>>>> Thanks,
>>>> Pallavi Sonal.
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>> Sent: Thursday, September 20, 2018 6:38 PM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>>> should handle offsets
>>>>
>>>> Thanks for the update.
>>>>
>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
>>>> eg. a negative offset at MAX or a positive offset at MIN.
>>>>
>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>>>> Here is the updated webrev for review :
>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Pallavi Sonal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>> Sent: Thursday, September 20, 2018 2:50 AM
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>>>> should handle offsets
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> The proposed fix does not tackle the bug fully. The bug is that 
>>>>> the spec says
>>>>>
>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>>>>>
>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>>>>>
>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>>>>>
>>>>> Furthermore, although there are numerous valid ISO-8601 ways of 
>>>>> saying zero, this format uses dashes and colons in the date/time 
>>>>> part, so
>>>>> ISO-8601 restricts the offset to only those formats that include colons.
>>>>>
>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the changes to the following issue:
>>>>>>
>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>>>>>>
>>>>>>
>>>>>>
>>>>>> The proposed fix is located at:
>>>>>>
>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>>>>>>
>>>>>>
>>>>>>
>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Pallavi Sonal
>>>>>>
>>>>>>
>>>>>>
>>>>>>

--
Thanks, Roger


From roger.riggs at oracle.com  Fri Sep 28 12:45:21 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 28 Sep 2018 08:45:21 -0400
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
 <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
 <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>
 <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default>
Message-ID: <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com>

Hi Pallavi,

Looks fine,

But can you re-wrap the lines with the new links, they got longer than 
100 chars with the link.

No new webrev is needed.

Thanks, Roger


On 9/28/18 8:35 AM, Pallavi Sonal wrote:
> Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
>
> Thanks,
> Pallavi Sonal
>
> -----Original Message-----
> From: Roger Riggs
> Sent: Friday, September 28, 2018 12:51 AM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
>
> Hi Pallavi,
>
> I'd suggest using @link for the reference (in both files).
> It will be easier for the reader to traverse and understand the pattern.
>
> DateTimeFormatterBuilder.java: line 836.
> The trailing "</p>" should be omitted so the readability of the source is maintained.
>
> Otherwise, looks good,
>
> Thanks, Roger
>
>
>
> On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
>> In DateTimeFormatter you need to qualify the @code part to refer to
>> DateTimeFormatterBuilder.
>> Otherwise good.
>> thanks
>> Stephen
>>
>>
>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>> Thanks for the clarification. Here is the updated webrev for review :
>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>>>
>>> Thanks,
>>> Pallavi Sonal
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne <scolebourne at joda.org>
>>> Sent: Tuesday, September 25, 2018 4:39 PM
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>>> handle offsets
>>>
>>> I think it makes sense for both, although I was only considering
>>> appendInstant() when I wrote it.
>>> Stephen
>>>
>>>
>>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>> Hi Stephen,
>>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>> Sent: Sunday, September 23, 2018 12:36 PM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>>>> handle offsets
>>>>
>>>> Thanks
>>>>
>>>> Can we change the docs to:
>>>>
>>>> <p>
>>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
>>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>>>>>     http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Pallavi Sonal.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>> Sent: Thursday, September 20, 2018 6:38 PM
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>> should handle offsets
>>>>>
>>>>> Thanks for the update.
>>>>>
>>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
>>>>> eg. a negative offset at MAX or a positive offset at MIN.
>>>>>
>>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>>>>> Here is the updated webrev for review :
>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Pallavi Sonal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>>> Sent: Thursday, September 20, 2018 2:50 AM
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>>> should handle offsets
>>>>>>
>>>>>> Thanks for looking at this.
>>>>>>
>>>>>> The proposed fix does not tackle the bug fully. The bug is that
>>>>>> the spec says
>>>>>>
>>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>>>>>>
>>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>>>>>>
>>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
>>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>>>>>>
>>>>>> Furthermore, although there are numerous valid ISO-8601 ways of
>>>>>> saying zero, this format uses dashes and colons in the date/time
>>>>>> part, so
>>>>>> ISO-8601 restricts the offset to only those formats that include colons.
>>>>>>
>>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>>>>>>
>>>>>> thanks
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the changes to the following issue:
>>>>>>>
>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The proposed fix is located at:
>>>>>>>
>>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Pallavi Sonal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
> --
> Thanks, Roger
>


From pavel.rappo at oracle.com  Fri Sep 28 12:56:48 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 28 Sep 2018 13:56:48 +0100
Subject: Reactive Streams utility API
In-Reply-To: <CABY0rKNFK0zviVDR0pbHjyL7xsOf9XYN1QH2n3BYNU=ScE2gGw@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>
 <03157EE0-B511-4733-B44E-82B838952DE0@oracle.com>
 <CABY0rKMa5wWTDTa-VhiYBhwkxvPZm-GFhQ86McuZ+cj9FtdKhw@mail.gmail.com>
 <10ADC503-F103-4426-8D75-666E8ED6C39D@oracle.com>
 <CABY0rKPiKd6gTQ6eUrcq8WQPDTEMgzEm1=vWSaxfDOhbVkn+Yg@mail.gmail.com>
 <4CFA6A61-4DCE-4C99-A879-D7AB4439020C@oracle.com>
 <CABY0rKNFK0zviVDR0pbHjyL7xsOf9XYN1QH2n3BYNU=ScE2gGw@mail.gmail.com>
Message-ID: <54D03C6A-A80B-451D-8330-57C824F0718F@oracle.com>


> On 26 Sep 2018, at 02:41, James Roper <james at lightbend.com> wrote:
> 
> Sounds good to me, I'll ping Viktor to make sure he sees it too.

The "Synchronization primitives in Reactive Streams implementations" thread on
concurrency-interest mailing list:

    http://cs.oswego.edu/pipermail/concurrency-interest/2018-September/016587.html

-Pavel


From volker.simonis at gmail.com  Fri Sep 28 13:55:11 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 28 Sep 2018 15:55:11 +0200
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
 <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
Message-ID: <CA+3eh138BFLd4dEOcnnCVtYhOncBeTdNaREPm2DdbY2BTvM3GA@mail.gmail.com>

Hi Andrew,

I agree that the native code should be fixed and I think your patch is correct.

Nevertheless I'd vote for changing it to something like:

old = (tio.c_lflag & ECHO) == 0 ? JNI_FALSE : JNI_TRUE;

It's slightly more verbose, but it makes it more obvious that a JNI
function returning a jboolean should only ever return JNI_FALSE or
JNI_TRUE. This isn't obvious from your fix - especially not for C
programmers who produce such code.

Also, it would be good to change the bug summary to something more
generic like "Fix native library code which does not return a clean
boolean" and fix the additional occurrences of this antipattern
reported by Matthias in this mail thread:
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/thread.html#1986
I think it would makelittle sense to open a new issue for each of
them.

Regards,
Volker

On Wed, Sep 26, 2018 at 8:54 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 09/26/2018 06:07 PM, Ichiroh Takiguchi wrote:
> > Sorry for bad operation.
> > In case of s390x platform, this issue was fixed by JDK-8209637.
> > https://bugs.openjdk.java.net/browse/JDK-8209637
> >
> > If you could recreate this issue, please check JVM side also.
>
> That does not fix the bug, except by accident. The native code should
> be fixed too.
>
> See the explanation in
> https://bugs.openjdk.java.net/browse/JDK-8211163
>
> --
> 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 aph at redhat.com  Fri Sep 28 14:13:25 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 28 Sep 2018 15:13:25 +0100
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <CA+3eh138BFLd4dEOcnnCVtYhOncBeTdNaREPm2DdbY2BTvM3GA@mail.gmail.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
 <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
 <CA+3eh138BFLd4dEOcnnCVtYhOncBeTdNaREPm2DdbY2BTvM3GA@mail.gmail.com>
Message-ID: <506a7c99-7ac2-6e37-d394-6594acd59346@redhat.com>

On 09/28/2018 02:55 PM, Volker Simonis wrote:
> I agree that the native code should be fixed and I think your patch is correct.
> 
> Nevertheless I'd vote for changing it to something like:
> 
> old = (tio.c_lflag & ECHO) == 0 ? JNI_FALSE : JNI_TRUE;
> 
> It's slightly more verbose, but it makes it more obvious that a JNI
> function returning a jboolean should only ever return JNI_FALSE or
> JNI_TRUE. This isn't obvious from your fix - especially not for C
> programmers who produce such code.

Where is the evidence that a function returning a jboolean should only
ever return JNI_FALSE or JNI_TRUE? It doesn't say so in the JNI spec,
only that these values are provided for convenience. They are defined
to be 0 and 1, like so:

#define JNI_FALSE  0
#define JNI_TRUE   1

which are *exactly* the same values that the C != operation
returns. Therefore there is no advantage either in correctness or
clarity gained by using

  ? JNI_FALSE : JNI_TRUE

It's not even pedantically correct, merely verbose.

> Also, it would be good to change the bug summary to something more
> generic like "Fix native library code which does not return a clean
> boolean" and fix the additional occurrences of this antipattern
> reported by Matthias in this mail thread:
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/thread.html#1986
> I think it would makelittle sense to open a new issue for each of
> them.

Probably.

-- 
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 christoph.langer at sap.com  Fri Sep 28 15:00:59 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 28 Sep 2018 15:00:59 +0000
Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <cb3062caf80e4fd5b33febd44cf1dbcf@sap.com>
References: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
 <c3d87005-bb35-b23a-b702-e8fd2fa1e9c7@oracle.com>
 <cb3062caf80e4fd5b33febd44cf1dbcf@sap.com>
Message-ID: <b421f67122ca47f0949be403c6a5abbe@sap.com>

Ping...

Are there any reviews/comments on my proposal for adding unix/posix permissions to zip APIs?

Thanks
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 26. September 2018 09:49
> To: 'Alan Bateman' <Alan.Bateman at oracle.com>; core-libs-
> dev at openjdk.java.net; nio-dev <nio-dev at openjdk.java.net>; Xueming
> Shen <xueming.shen at oracle.com>
> Cc: Volker Simonis <volker.simonis at gmail.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Subject: RE: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
> permissions of the files
> 
> Hi Alan,
> 
> thanks for your initial comments.
> 
> > One initial comment is that you should be able to drop the API additions to
> > PosxFilePermissions - I think all you need there translation from
> > Set<PosixFilePermission> to internal values, it doesn't require bloating the
> > API.
> 
> I agree, it doesn't feel right to bloat PosixFilePermissions with details needed
> for zip operations.
> 
> I now moved this coding to the ZipUtils classes. The only drawback is the
> duplication of the code but there's already quite some duplication of coding
> between java.util.zip and jdk.nio.zipfs.
> 
> Here is an updated webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/6194856.1/
> 
> Best regards
> Christoph

From volker.simonis at gmail.com  Fri Sep 28 15:08:32 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 28 Sep 2018 17:08:32 +0200
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <506a7c99-7ac2-6e37-d394-6594acd59346@redhat.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
 <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
 <CA+3eh138BFLd4dEOcnnCVtYhOncBeTdNaREPm2DdbY2BTvM3GA@mail.gmail.com>
 <506a7c99-7ac2-6e37-d394-6594acd59346@redhat.com>
Message-ID: <CA+3eh12A54jjauM4t-iaZ5K53LgFQBPb0bNC2bjmuDcb+QhDfA@mail.gmail.com>

On Fri, Sep 28, 2018 at 4:13 PM Andrew Haley <aph at redhat.com> wrote:
>
> On 09/28/2018 02:55 PM, Volker Simonis wrote:
> > I agree that the native code should be fixed and I think your patch is correct.
> >
> > Nevertheless I'd vote for changing it to something like:
> >
> > old = (tio.c_lflag & ECHO) == 0 ? JNI_FALSE : JNI_TRUE;
> >
> > It's slightly more verbose, but it makes it more obvious that a JNI
> > function returning a jboolean should only ever return JNI_FALSE or
> > JNI_TRUE. This isn't obvious from your fix - especially not for C
> > programmers who produce such code.
>
> Where is the evidence that a function returning a jboolean should only
> ever return JNI_FALSE or JNI_TRUE? It doesn't say so in the JNI spec,
> only that these values are provided for convenience. They are defined
> to be 0 and 1, like so:
>
> #define JNI_FALSE  0
> #define JNI_TRUE   1
>
> which are *exactly* the same values that the C != operation
> returns. Therefore there is no advantage either in correctness or
> clarity gained by using
>
>   ? JNI_FALSE : JNI_TRUE
>
> It's not even pedantically correct, merely verbose.
>

Yes, but the next developer who adds a function which returns jboolean
and looks at your implementation could easily introduce new,  buggy
code like the one you fixed (because from a C-perspective that makes
no difference). But if he sees that other JNI functions all return
exclusively JNI_TRUE/JNI_FALSE he may be  inclined to do so as well.

> > Also, it would be good to change the bug summary to something more
> > generic like "Fix native library code which does not return a clean
> > boolean" and fix the additional occurrences of this antipattern
> > reported by Matthias in this mail thread:
> > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/thread.html#1986
> > I think it would makelittle sense to open a new issue for each of
> > them.
>
> Probably.
>
> --
> 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 henry.jen at oracle.com  Fri Sep 28 15:15:06 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 28 Sep 2018 08:15:06 -0700
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <77ab8e11-6581-8b73-ad2d-782c0f4d28d7@oracle.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
 <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
 <77ab8e11-6581-8b73-ad2d-782c0f4d28d7@oracle.com>
Message-ID: <A9F1F1A7-3AAA-4C1C-B0E4-1BC83B75FD91@oracle.com>

Will do.

Cheers,
Henry


> On Sep 28, 2018, at 3:23 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 27/09/2018 17:49, Henry Jen wrote:
>> Agree, please find updated webrev[1].
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
>> 
>> 
> This looks okay to me, you may want to consider adding 8210810 to the @bug tag before pushing.
> 
> -Alan


From dmitry.nadezhin at gmail.com  Fri Sep 28 15:15:28 2018
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 28 Sep 2018 18:15:28 +0300
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces
 incorrect results
In-Reply-To: <C5D73548-C985-4630-AE31-49762F17E8FC@oracle.com>
References: <ec4a2e17-7b98-dc4f-7f2f-c9b8e105db9b@gmail.com>
 <d7141a10-6868-73a7-7b9c-00a816f8c075@redhat.com>
 <CALS-RZL+JVDJf0b2Atvw7KwxKiatX+VDu_qeEVtWyXh=7RH6fA@mail.gmail.com>
 <e170c8e5-d565-1fbd-b597-df7340d71bf4@gmail.com>
 <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com>
 <2181f074-15b8-ed37-2f64-b675249216ac@gmail.com>
 <C5D73548-C985-4630-AE31-49762F17E8FC@oracle.com>
Message-ID: <CAAUNa5sPFNsd1t6gzHR8cV9R4u6ZGzDYg4y7nYHLspka9qB63g@mail.gmail.com>

I would like to tell about some steps towards formal check of Raffaello's
human proof.
I work on formal verification of some Oracle projects but they are
unrelated to JDK.
In April Brian Burkhalter requested me to review the Raffaello's paper.
His paper is smart and clear but nevertheless I was afraid to miss some
possible error in his it.
So I decided to check his proofs formally. I am familiar with a proof
checker ACL2 [1]. So I used it.
ACL2 is an abbreviation of "Applicative Common Lisp". It is both a language
( a subset of Common Lisp ) and
proof assistant for reasoning about functions in this language. It is
open-source and it is developed in UT at Austin.

This work in progress can be found in this GitHub repository [2].
ACL2 definitions and proofs followed human definitions and proofs as
possible.
Materials of N-th section of the paper are in a file acl2/sectionN.lisp .
Proofs from sections 2-10 were checked by ACL2 completely.
Also cases fullCaseXS and fullCaseXM from the sections 2-11 were checked by
ACL2.
Sorry, I didn't finish formal proof of the entire paper in anticipation of
a new algorithm.

Sometimes in July a paper by Michel Hack [3] prompted us that it is
possible to avoid multi-precision arithmetic.
File acl2/cont-fractions.lisp formalizes some of Michel's ideas in ACL2.
It considers a linear mapping alpha*d from range of naturals 0 <= d <=
max-d to rationals.
It defines an algorithms which for given alpha and "max-d" returns bound
"lo" and "hi"
how non-integer results of this mapping are frar from integer grid.
If approximate computations shows that alpha*d is very close to some
integer m
m - hi < alpha * d < m + lo
then alpha * d is equal to m exactly.
Theorems frac-alpha-d-nonzero-bound-dp-correct and
frac-alpha-d-nonzero-bound-sp-correct explicitly
state bounds lo and hi for float and double Java formats.
This fact is proved using continous fractions.

Raffaello derived from this theorem that a table of powers of 5 with
126-bit precision is enough
to correctly implement DoubleToString conversion.
He designed a new implementation of DoubleToString and FloatToString and
presented it in this core-libs-dev thread.

It was exciting to know that Ulf Adama also developed fast conversion
algorithm.
New Raffaello's and Ulf's algorithms looks similar.
It would be interesting to compare them, to match similarities and to think
on differences.
For example the problem of finding "lo" and "hi" is formulated as computing
minimum and maximum of a modular product in Ilf's paper.
It would be interesting to check if our lo-hi bounds are scaled versions of
Ulf's minimum and maximum.
Ideally it would be interesting to formally verify both of them though I am
not sure if I find time for this.

If Raffaello prepares a new paper with proof of his new algorithm then I
will try to check these new proofs by ACL2 again.
I hope that paper with its formal check will increase confidence.

---

Andrew Dinn said about other problem: "how details of specific coding
operations are not always clearly
identifiable from an abstract mathematical treatment.". Formal verification
is applicable for this also.
It can be done either at Java language level or at classfile level.

Verification at classfile level requires formal model of JVM.
There are at least three models of JVM in ACL2:
i) An M5 model in the distribution of ACL2 books: [4]
ii) Defensive JVM model by CLI: [5]
iii) M6 model by Hamling Liu: [6]

Verification at Java language level can be done using other tools,
especially the KeY tool: [7].
TimSort bug [8][ has been found during to attempt to verify this
alogorithm's implementation by KeY.

Unfortunately I am not sure that I find time to verify implementation
(classfile or Java-file) of the new Raffaello algorithm.

---

[1] http://www.cs.utexas.edu/~moore/acl2/

[2] https://github.com/nadezhin/verify-todec

[3]
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.8351&rep=rep1&type=pdf#page=114

[4] https://github.com/acl2/acl2/tree/master/books/models/jvm/m5

[5] http://www.computationallogic.com/software/djvm/index.html

[6] https://github.com/haliu/M6

[7] https://www.key-project.org/

[8]
http://www.envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

On Fri, Sep 28, 2018 at 1:11 AM Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Sep 27, 2018, at 9:00 AM, Raffaello Giulietti <
> raffaello.giulietti at gmail.com> wrote:
>
> > On 2018-09-27 17:53, Andrew Dinn wrote:
> >> On 27/09/18 16:37, Raffaello Giulietti wrote:
> >>   . . .
> >>> I thank you in advance for your willingness to review the code but my
> >>> understanding is that only the officially appointed reviewers can
> >>> approve OpenJDK contributions, which is of course a good policy.
> >>> Besides, as two Andrews engineers from RedHat correctly observe,
> >>> understanding the rationale of the code without the planned
> accompanying
> >>> paper is hard.
> >> Oh no, let me stop you right there! Anyone competent can offer a review
> >> (well incompetent people can too but let's assume they get ignored :-).
> >> Indeed, an expert critique is always very welcome and reviewers normally
> >> get credited even if they have no official status. The official
> >> reviewers are needed for a final say so. No one sensible is going to
> >> reject clear and clearly justified advice.
> >
> > An excellent policy, indeed!
>
> I was going to reply with essentially the same comments. While an
> imprimatur from at least one sanctioned OpenJDK reviewer is required
> eventually, comments and review from any competent parties are most
> welcome. This is especially the case for a relatively complicated topic
> such as the one of this thread.
>
> >>>> I'm not a contributor to the Jdk, and this isn't my full-time job. I
> >>>> was lurking here because I was going to send a patch for the double to
> >>>> string conversion code myself (based on Ryu).
> >>>>
> >>>
> >>> All my efforts on this projects are done in my unpaid spare time, too.
> >> Which is very much appreciated, thank you.
> >
> > Thank all of you for your interest in this issue.
>
> I would like to second that. It is great to see so many comments on this
> topic and to have knowledgable people paying attention.
>
> Brian

From henry.jen at oracle.com  Fri Sep 28 15:17:21 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 28 Sep 2018 08:17:21 -0700
Subject: [RFR] 8210810: Escaped character at specific position in argument
 file is not handled properly
In-Reply-To: <8ADC77BE-689F-4876-904C-8B46F7226C64@gmail.com>
References: <83EAA93A-ACFC-4B85-9DCB-58BBE22019D7@gmail.com>
 <2D755B1A-6F41-497A-BED6-BA51A9B08F8B@gmail.com>
 <6868F6DD-71DB-4FC7-96C8-3A184ECE786C@oracle.com>
 <67AFDBD7-EC57-483F-A56B-13FFCCF4A7CF@gmail.com>
 <5A83CAA6-C063-4CCE-ADE4-D3DCB2EC699F@oracle.com>
 <c5c9d5b4-ff94-5c62-f729-96d356c8ee44@oracle.com>
 <36B464E5-0E65-417E-A77A-96FF09DF8DC1@oracle.com>
 <8ADC77BE-689F-4876-904C-8B46F7226C64@gmail.com>
Message-ID: <EB4A27A3-0731-4301-9242-6E22C056DC0F@oracle.com>

I?ll create back port requests.

Cheers,
Henry


> On Sep 27, 2018, at 11:06 PM, Bo Zhang <zhangbodut at gmail.com> wrote:
> 
> Thanks Henry, this change looks good to me. I assume this patch will be backported to 11GA, will it be back ported to 10 as well?
> 
> Regards,
> Bo
> 
>> On 28 Sep 2018, at 00:49, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> Agree, please find updated webrev[1].
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
>> 
>> Cheers,
>> Henry
>> 
>> 
>>> On Sep 27, 2018, at 1:45 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 27/09/2018 03:58, Henry Jen wrote:
>>>> Hi,
>>>> 
>>>> Need a quick review of the webrev[1] for JDK-8210810[2], it?s pretty much what Bo contributed, just add some trailing text ?aaa\? to verify the integrity of escape sequence is handled properly.
>>>> 
>>>> I had reviewed the change and tested, but we need a ?R?eviewer.
>>>> 
>>>> Cheers,
>>>> Henry
>>>> 
>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/webrev/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8210810
>>>> 
>>>> 
>>> The change to args.c looks okay but for the test then I assume it would be better to just add another test case to the existing ArgFileSyntax.java.
>>> 
>>> -Alan
>> 
> 


From pallavi.sonal at oracle.com  Fri Sep 28 15:53:24 2018
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Fri, 28 Sep 2018 08:53:24 -0700 (PDT)
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
 <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
 <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>
 <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default>
 <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com>
Message-ID: <a411f399-f75a-4e2f-a009-712e238bae2f@default>

Thanks Roger. I will update it before the commit.

-----Original Message-----
From: Roger Riggs 
Sent: Friday, September 28, 2018 6:15 PM
To: Pallavi Sonal <pallavi.sonal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Hi Pallavi,

Looks fine,

But can you re-wrap the lines with the new links, they got longer than
100 chars with the link.

No new webrev is needed.

Thanks, Roger


On 9/28/18 8:35 AM, Pallavi Sonal wrote:
> Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
>
> Thanks,
> Pallavi Sonal
>
> -----Original Message-----
> From: Roger Riggs
> Sent: Friday, September 28, 2018 12:51 AM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> handle offsets
>
> Hi Pallavi,
>
> I'd suggest using @link for the reference (in both files).
> It will be easier for the reader to traverse and understand the pattern.
>
> DateTimeFormatterBuilder.java: line 836.
> The trailing "</p>" should be omitted so the readability of the source is maintained.
>
> Otherwise, looks good,
>
> Thanks, Roger
>
>
>
> On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
>> In DateTimeFormatter you need to qualify the @code part to refer to 
>> DateTimeFormatterBuilder.
>> Otherwise good.
>> thanks
>> Stephen
>>
>>
>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>> Thanks for the clarification. Here is the updated webrev for review :
>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>>>
>>> Thanks,
>>> Pallavi Sonal
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne <scolebourne at joda.org>
>>> Sent: Tuesday, September 25, 2018 4:39 PM
>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
>>> handle offsets
>>>
>>> I think it makes sense for both, although I was only considering
>>> appendInstant() when I wrote it.
>>> Stephen
>>>
>>>
>>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>> Hi Stephen,
>>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>> Sent: Sunday, September 23, 2018 12:36 PM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>>> should handle offsets
>>>>
>>>> Thanks
>>>>
>>>> Can we change the docs to:
>>>>
>>>> <p>
>>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
>>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>>>>>     http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Pallavi Sonal.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>> Sent: Thursday, September 20, 2018 6:38 PM
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>>>> should handle offsets
>>>>>
>>>>> Thanks for the update.
>>>>>
>>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
>>>>> eg. a negative offset at MAX or a positive offset at MIN.
>>>>>
>>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>>>>> Here is the updated webrev for review :
>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Pallavi Sonal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>>> Sent: Thursday, September 20, 2018 2:50 AM
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>>>>> should handle offsets
>>>>>>
>>>>>> Thanks for looking at this.
>>>>>>
>>>>>> The proposed fix does not tackle the bug fully. The bug is that 
>>>>>> the spec says
>>>>>>
>>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>>>>>>
>>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>>>>>>
>>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
>>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>>>>>>
>>>>>> Furthermore, although there are numerous valid ISO-8601 ways of 
>>>>>> saying zero, this format uses dashes and colons in the date/time 
>>>>>> part, so
>>>>>> ISO-8601 restricts the offset to only those formats that include colons.
>>>>>>
>>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>>>>>>
>>>>>> thanks
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the changes to the following issue:
>>>>>>>
>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The proposed fix is located at:
>>>>>>>
>>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Pallavi Sonal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
> --
> Thanks, Roger
>


From naoto.sato at oracle.com  Fri Sep 28 16:07:57 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 28 Sep 2018 09:07:57 -0700
Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
 offsets
In-Reply-To: <a411f399-f75a-4e2f-a009-712e238bae2f@default>
References: <38b8864c-e283-44f7-a962-aa65fb560b79@default>
 <CACzrW9DSi0h2aPDSV=RGcYtA47bjpiRseGOdt2-mnKiCPNQ-EQ@mail.gmail.com>
 <871fb443-47c9-4860-815a-5d2064118fbb@default>
 <CACzrW9DVSmUpfKByfiw=NmXYXDKODNQyGDVrHG6wB=ZjNSqz0g@mail.gmail.com>
 <d19289fb-46e8-4f71-a9b5-cbd0f4d85dd9@default>
 <CACzrW9D1jfXDuUxL+frVbDFJ7ikWZz4eP_6iJc=drY+om3u1EQ@mail.gmail.com>
 <65120bb8-af2a-4144-a334-f1057c21fbf6@default>
 <CACzrW9CUM39atBpBb_5NHa9sKMob7yrdrLuqLiv_h62kLbi43Q@mail.gmail.com>
 <0b15557a-a158-4f79-be93-d5a18ac950a2@default>
 <CACzrW9DPdsWucHJuicqbxhnt_aHv6JhVMxq1Epot2zTJRvLeZg@mail.gmail.com>
 <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com>
 <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default>
 <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com>
 <a411f399-f75a-4e2f-a009-712e238bae2f@default>
Message-ID: <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com>

Hi Pallavi,

Please file a CSR for this, as this will change the behavior.

Naoto

On 9/28/18 8:53 AM, Pallavi Sonal wrote:
> Thanks Roger. I will update it before the commit.
> 
> -----Original Message-----
> From: Roger Riggs
> Sent: Friday, September 28, 2018 6:15 PM
> To: Pallavi Sonal <pallavi.sonal at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
> 
> Hi Pallavi,
> 
> Looks fine,
> 
> But can you re-wrap the lines with the new links, they got longer than
> 100 chars with the link.
> 
> No new webrev is needed.
> 
> Thanks, Roger
> 
> 
> On 9/28/18 8:35 AM, Pallavi Sonal wrote:
>> Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
>>
>> Thanks,
>> Pallavi Sonal
>>
>> -----Original Message-----
>> From: Roger Riggs
>> Sent: Friday, September 28, 2018 12:51 AM
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>> handle offsets
>>
>> Hi Pallavi,
>>
>> I'd suggest using @link for the reference (in both files).
>> It will be easier for the reader to traverse and understand the pattern.
>>
>> DateTimeFormatterBuilder.java: line 836.
>> The trailing "</p>" should be omitted so the readability of the source is maintained.
>>
>> Otherwise, looks good,
>>
>> Thanks, Roger
>>
>>
>>
>> On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
>>> In DateTimeFormatter you need to qualify the @code part to refer to
>>> DateTimeFormatterBuilder.
>>> Otherwise good.
>>> thanks
>>> Stephen
>>>
>>>
>>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>> Thanks for the clarification. Here is the updated webrev for review :
>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
>>>>
>>>> Thanks,
>>>> Pallavi Sonal
>>>>
>>>> -----Original Message-----
>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>> Sent: Tuesday, September 25, 2018 4:39 PM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
>>>> handle offsets
>>>>
>>>> I think it makes sense for both, although I was only considering
>>>> appendInstant() when I wrote it.
>>>> Stephen
>>>>
>>>>
>>>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>> Hi Stephen,
>>>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>> Sent: Sunday, September 23, 2018 12:36 PM
>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>> should handle offsets
>>>>>
>>>>> Thanks
>>>>>
>>>>> Can we change the docs to:
>>>>>
>>>>> <p>
>>>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
>>>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review :
>>>>>>      http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>> Pallavi Sonal.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>>> Sent: Thursday, September 20, 2018 6:38 PM
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>>> should handle offsets
>>>>>>
>>>>>> Thanks for the update.
>>>>>>
>>>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid.
>>>>>> eg. a negative offset at MAX or a positive offset at MIN.
>>>>>>
>>>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed.
>>>>>>
>>>>>> thanks
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>>>>>> Here is the updated webrev for review :
>>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Pallavi Sonal
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>>>> Sent: Thursday, September 20, 2018 2:50 AM
>>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
>>>>>>> should handle offsets
>>>>>>>
>>>>>>> Thanks for looking at this.
>>>>>>>
>>>>>>> The proposed fix does not tackle the bug fully. The bug is that
>>>>>>> the spec says
>>>>>>>
>>>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..."
>>>>>>>
>>>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.
>>>>>>>
>>>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId.
>>>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that.
>>>>>>>
>>>>>>> Furthermore, although there are numerous valid ISO-8601 ways of
>>>>>>> saying zero, this format uses dashes and colons in the date/time
>>>>>>> part, so
>>>>>>> ISO-8601 restricts the offset to only those formats that include colons.
>>>>>>>
>>>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext.
>>>>>>>
>>>>>>> thanks
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal <pallavi.sonal at oracle.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the changes to the following issue:
>>>>>>>>
>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The proposed fix is located at:
>>>>>>>>
>>>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].  With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Pallavi Sonal
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> --
>> Thanks, Roger
>>
> 

From Sergey.Bylokhov at oracle.com  Fri Sep 28 19:42:02 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 28 Sep 2018 12:42:02 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method in
 Java
In-Reply-To: <a85eaf4e-fb4f-5bc2-00d7-061d8b99b41f@oracle.com>
References: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
 <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>
 <CAE+3fjZpssja+6a5nsvdZerr34R-ow7U2VQNnCCCyAFR+9OW1A@mail.gmail.com>
 <a85eaf4e-fb4f-5bc2-00d7-061d8b99b41f@oracle.com>
Message-ID: <d10e1411-c0e9-2128-6c6b-c3f7bf9da9ac@oracle.com>

I can review the changes in java.desktop, please use these email alias 
awt-dev/2d-dev/swing-dev.

On 28/09/2018 04:13, Alan Bateman wrote:
> As regards doing the entire source base then I think that would be good. 
> Due to the complexity of testing, changes to the java.desktop module are 
> pushed to jdk/client repo rather than jdk/jdk so if it's not too awkward 
> then it might be helper if the patch for java.desktop were a separate 
> change that gets pushed to jdk/client rather than jdk/jdk.


-- 
Best regards, Sergey.

From stuart.marks at oracle.com  Fri Sep 28 20:12:44 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 28 Sep 2018 13:12:44 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <2cdc5a22-0217-b985-9069-0fc72058f081@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
 <2cdc5a22-0217-b985-9069-0fc72058f081@redhat.com>
Message-ID: <51f1741a-7854-a8fb-3d25-b4cd7fcfd7bf@oracle.com>



On 9/28/18 2:16 AM, Andrew Dinn wrote:
> Thanks for clarifying that point. I have already added a note to that
> effect to the JEP. I take your other point that these limitations make
> this JEP a less useful addition than it could be. However, it's hard to
> see what else might usefully be provided that does not involve a
> reworking of JDK core-lib (and, potentially, JVM) functionality that has
> a much larger scope than is needed to crack the specific nut the JEP
> addresses.

I'm not sure I'd put it quite that way, "less useful than it could be."

I guess it depends on what you think the JEP is about. If the JEP is about MBB, 
and MBB is at some point superseded by something else, then yes, I suppose that 
means this JEP is less useful than it might be.

On the other hand, suppose that this JEP is primarily about NVM, including 
access, operations, API, architecture, life cycle issues, etc., and these happen 
to be surfaced through MBB today. If something supersedes MBB, then the concepts 
developed by this JEP can be retargeted to that other thing at the appropriate 
time. Or are the concepts developed by this JEP so closely intertwined with MBB 
that this idea of "retargeting" doesn't make sense? I don't know.

> Thank you for a very clear and interesting summary of the limitations of
> the Buffer API. I have cut it from this reply for the sake of brevity
> but I will respond to a few points.

Great, I'm glad this helped. I'm never quite sure whether writing these big 
essays is helpful.

(Note also that there are OTHER limitations of the buffer API that I didn't 
cover, since the message was getting too long as it was. Example: 2GB limit.)

> I think the limitations you point out regarding concurrent clients' mode
> of operation are less severe in this specific case because there is not
> really a need for those client threads to reach a rendezvous point in
> order to execute some form of FileChannel update. The buffer content is
> persistent memory. So, essentially, the data writes constitute the update.

Sure. It may be that the use cases for NVM aren't particularly affected by 
limitations of the Buffer APIs. If so, so much the better! But there are other 
systems where the limitations imposed by buffers are so onerous that they've had 
to go directly to Unsafe.

> Anyway, thank you for a clear warning as to the precise perils faced in
> implementing correct client libraries over the base layer this JEP proposes.

Yes, this is essentially it. When you run into a problem -- as every project 
does -- think about whether it's inherent to NVM, or whether it's incidental to 
NVM and is rooted in the use of Buffers.

s'marks

From stuart.marks at oracle.com  Fri Sep 28 20:50:44 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 28 Sep 2018 13:50:44 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
 <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.com>
Message-ID: <e9cb6a30-8025-6c1b-88ff-e18e6778ce9d@oracle.com>



On 9/28/18 12:21 AM, Peter Levart wrote:
> I mostly agree with your assessment about the suitability of the ByteBuffer API 
> for nice multithreaded use. What would such API look like? I think pretty much 
> like ByteBuffer but without things that mutate mark/position/limit/ByteOrder. A 
> stripped-down ByteBuffer API therefore. That would be in my opinion the most 
> low-level API possible. If you add things to such API that coordinate 
> multithreaded access to the underlying memory, you are already creating a 
> concurrent data structure for a particular set of use cases, which might not 
> cover all possible use cases or be sub-optimal at some of them. So I think this 
> is better layered on top of such API not built into it. Low-level multithreaded 
> access to memory is, in my opinion, always going to be "unsafe" from the 
> standpoint of coordination. It's not only the mark/position/limit/ByteOrder that 
> is not multithreaded-friendly about ByteBuffer API, but the underlying memory 
> too. It would be nice if mark/position/limit/ByteOrder weren't in the way though.

Right, getting mark/position/limit/ByteOrder out of the way would be a good 
first step. (I just realized that ByteOrder is mutable too!)

I also think you're right that proceeding down a "classic" thread-safe object 
design won't be fruitful. We don't know what the right set of operations is yet, 
so it'll be difficult to know how to deal with thread safety.

One complicating factor is timely deallocation. This is an existing problem with 
direct buffers and MappedByteBuffer (see JDK-4724038). If a "buffer" were 
confined to a single thread, it could be deallocated safely when that thread is 
finished. I don't know how to guarantee thread confinement though.

On the other hand, if a "buffer" is exposed to multiple threads, deallocation 
requires that proper synchronization and checking be done so that subsequent 
operations are properly checked (so that they do something reasonable, like 
throw an exception) instead of accessing unmapped or repurposed memory. If 
checking is done, this pushes operations to be coarser-grained (bulk) so that 
the checking overhead is amortized over a more expensive operation.

I know there has been some thought put into this in the Panama project, but I 
don't know exactly where it stands at the moment. See the MemoryRegion and Scope 
stuff.

s'marks

From stuart.marks at oracle.com  Fri Sep 28 21:14:00 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 28 Sep 2018 14:14:00 -0700
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <CAKxGtTWcunzwM=7K21Sk=VKrKfwVzWbAvONBK1nZAYqP-zihsg@mail.gmail.com>
References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com>
 <c31673fd-133f-56e7-2e82-77e5109be9fc@oracle.com>
 <e7a20676-e76e-27c6-a770-44382d4d77ad@redhat.com>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
 <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.com>
 <CAKxGtTWcunzwM=7K21Sk=VKrKfwVzWbAvONBK1nZAYqP-zihsg@mail.gmail.com>
Message-ID: <3fe9410d-2d20-c26c-a62e-cf9ad47b529a@oracle.com>

Hi Francesco,

Thanks for the pointer to AtomicBuffer stuff. It's quite interesting.

I don't know how directly relevant this JEP is your work. I guess that's really 
up to you and possibly Andrew Dinn. However, in my thinking, if you have useful 
comments and relevant questions, you're certainly welcome to participate in the 
discussion.

Looking at the AtomicBuffer interface, I see that it supports reading and 
writing of a variety of data items, with a few different memory access modes. 
That reminds me of the VarHandles API. [1] This enables quite a number of 
different operations on a data item somewhere in memory, with a variety of 
memory access modes. What would AtomicBuffer look like if it were to use 
VarHandles? Or would AtomicBuffer be necessary at all if the rest of the library 
were to use VarHandles?

Note that a VarHandle can be used to access an arbitrary item within a region of 
memory, such as an array or a ByteBuffer.[2] An obvious extension to VarHandle 
is to allow a long offset, not just an int offset.

Note also that while many VarHandle methods return Object and take a varargs 
parameter of Object..., this does not imply that primitives are boxed! This is a 
bit of VM magic called "signature polymorphism"; see JVMS 2.9.3 [3].

s'marks

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/VarHandle.html

[2] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandles.html#byteBufferViewVarHandle(java.lang.Class,java.nio.ByteOrder)

[3] https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-2.html#jvms-2.9.3

On 9/28/18 12:38 AM, Francesco Nigro wrote:
> Hi guys!
>
> I'm one of the mentioned devs (like many others) that are using external (and 
> unsafe) APIs to concurrent access ByteBuffer's content and a developer of a 
> messaging broker's journal
> that would benefit by this JEP :)
> Re concurrent access API, how it looks 
> https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/AtomicBuffer.java?
>
> note:
> I don't know how's considered to appear in these discussions without 
> presenting myself and I hope to not be OT, but both this JEP and the comments 
> around are so interesting
> that I couldn't resist: I apologize if I'm not respecting some rule on it
>
> Thanks for the hard work,
> Francesco
>
> Il giorno ven 28 set 2018 alle ore 09:21 Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> ha scritto:
>
>     Hi Stuart,
>
>     I mostly agree with your assessment about the suitability of the
>     ByteBuffer API for nice multithreaded use. What would such API look like?
>     I think pretty much like ByteBuffer but without things that mutate
>     mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore.
>     That would be in my opinion the most low-level API possible. If you add
>     things to such API that coordinate multithreaded access to the underlying
>     memory, you are already creating a concurrent data structure for a
>     particular set of use cases, which might not cover all possible use cases
>     or be sub-optimal at some of them. So I think this is better layered on
>     top of such API not built into it. Low-level multithreaded access to
>     memory is, in my opinion, always going to be "unsafe" from the standpoint
>     of coordination. It's not only the mark/position/limit/ByteOrder that is
>     not multithreaded-friendly about ByteBuffer API, but the underlying memory
>     too. It would be nice if mark/position/limit/ByteOrder weren't in the way
>     though.
>
>     Regards, Peter
>
>
>     On 09/28/2018 07:51 AM, Stuart Marks wrote:
>>     Hi Andrew,
>>
>>     Let me first stay that this issue of "ByteBuffer might not be the right
>>     answer" is something of a digression from the JEP discussion. I think the
>>     JEP should proceed forward using MBB with the API that you and Alan had
>>     discussed previously. At most, the discussion of the "right thing" issue
>>     might affect a side note in the JEP text about possible limitations and
>>     future directions of this effort. However, it's not a blocker to the JEP
>>     making progress as far as I'm concerned.
>>
>>     With that in mind, I'll discuss the issue of multithreaded access to
>>     ByteBuffers and how this bears on whether buffers are or aren't the
>>     "right answer." There are actually several issues that figure into the
>>     "right answer" analysis. In this message, though, I'll just focus on the
>>     issue of multithreaded access.
>>
>>     To recap (possibly for the benefit of other readers) the Buffer class doc
>>     has the following statement:
>>
>>     ??? Buffers are not safe for use by multiple concurrent threads. If a buffer
>>     ??? is to be used by more than one thread then access to the buffer
>>     should be
>>     ??? controlled by appropriate synchronization.
>>
>>     Buffers are primarily designed for sequential operations such as I/O or
>>     codeset conversion. Typical buffer operations set the mark, position, and
>>     limit before initiating the operation. If the operation completes
>>     partially -- not uncommon with I/O or codeset conversion -- the position
>>     is updated so that the operation can be resumed easily from where it left
>>     off.
>>
>>     The fact that buffers not only contain the data being operated upon but
>>     also mutable state information such as mark/position/limit makes it
>>     difficult to have multiple threads operate on different parts of the same
>>     buffer. Each thread would have to lock around setting the position and
>>     limit and performing the operation, preventing any parallelism. The
>>     typical way to deal with this is to create multiple buffer slices, one
>>     per thread. Each slice has its own mark/position/limit values but shares
>>     the same backing data.
>>
>>     We can avoid the need for this by adding absolute bulk operations, right?
>>
>>     Let's suppose we were to add something like this (considering ByteBuffer
>>     only, setting the buffer views aside):
>>
>>     ??? get(int srcOff, byte[] dst, int dstOff, int length)
>>     ??? put(int dstOff, byte[] src, int srcOff, int length)
>>
>>     Each thread can perform its operations on a different part of the buffer,
>>     in parallel, without interference from the others. Presumably these
>>     operations don't read or write the mark and position. Oh, wait. The
>>     existing absolute put and get overloads *do* respect the buffer's limit,
>>     so the absolute bulk operations ought to as well. This means they do
>>     depend on shared state. (I guess we could make the absolute bulk ops not
>>     respect the limit, but that seems inconsistent.)
>>
>>     OK, let's adopt an approach similar to what was described by Peter Levart
>>     a couple messages upthread, where a) there is an initialization step
>>     where various things including the limit are set properly; b) the buffer
>>     is published to the worker threads properly, e.g., using a lock or other
>>     suitable memory operation; and c) all worker threads agree only to use
>>     absolute operations and to avoid relative operations.
>>
>>     Now suppose the threads have completed their work and you want to, say,
>>     write the buffer's contents to a channel. You have to carefully make sure
>>     the threads are all finished and properly publish their results back to
>>     some central thread, have that central thread receive the results, set
>>     the position and limit, after which the central thread can initiate the
>>     I/O operation.
>>
>>     This can certainly be made to work.
>>
>>     But note what we just did. We now have an API where:
>>
>>     ?- there are different "phases", where in one phase all the methods work,
>>     but in another phase only certain methods work (otherwise it breaks
>>     silently);
>>
>>     ?- you have to carefully control all the code to ensure that the wrong
>>     methods aren't called when the buffer is in the wrong phase (otherwise it
>>     breaks silently); and
>>
>>     ?- you can't hand off the buffer to a library (3rd party or JDK) without
>>     carefully orchestrating a transition into the right phase (otherwise it
>>     breaks silently).
>>
>>     Frankly, this is pretty crappy. It's certainly possible to work around
>>     it. People do, and it is painful, and they complain about it up and down
>>     all day long (and rightfully so).
>>
>>     Note that this discussion is based primarily on looking at the ByteBuffer
>>     API. I have not done extensive investigation of the impact of the various
>>     buffer views (IntBuffer, LongBuffer, etc.), nor have I looked thoroughly
>>     at the implementations. I have no doubt that we will run into additional
>>     issues when we do those investigations.
>>
>>     If we were designing an API to support multi-threaded access to memory
>>     regions, it would almost certainly look nothing like the buffer API. This
>>     is what Alan means by "buffers might not be the right answer." As things
>>     stand, it appears quite difficult to me to fix the multi-threaded access
>>     problem without turning buffers into something they aren't, or
>>     fragmenting the API in some complex and uncomfortable way.
>>
>>     Finally, note that this is not an argument against adding bulk absolute
>>     operations! I think we should probably go ahead and do that anyway. But
>>     let's not fool ourselves into thinking that bulk absolute operations
>>     solve the multi-threaded buffer access problem.
>>
>>     s'marks
>>
>

From jonathan.gibbons at oracle.com  Fri Sep 28 22:06:05 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 28 Sep 2018 15:06:05 -0700
Subject: ByteArrayOutputStream should not have a new writeBytes method
 in Java
In-Reply-To: <a85eaf4e-fb4f-5bc2-00d7-061d8b99b41f@oracle.com>
References: <CAD4YxQWUvMtsCUK_HKhQh0tSRUirJS9tWctyKT4-uNnLFpjwig@mail.gmail.com>
 <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com>
 <CAE+3fjZpssja+6a5nsvdZerr34R-ow7U2VQNnCCCyAFR+9OW1A@mail.gmail.com>
 <a85eaf4e-fb4f-5bc2-00d7-061d8b99b41f@oracle.com>
Message-ID: <5BAEA5CD.8050601@oracle.com>



On 09/28/2018 04:13 AM, Alan Bateman wrote:
> On 28/09/2018 05:51, Tagir Valeev wrote:
>> Hello!
>>
>> I can volunteer doing this if OpenJDK community is really interested.
>> I've launched the inspection over all java.* and jdk.* modules and
>> found 4064 warnings.
>> As an example, I converted all C-style array declarations in java.base
>> module (660 warnings in 168 files). Here's the webrev:
>> http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/
>>
>> To me it's easier to review the whole patch rather than click on 
>> every file:
>> http://cr.openjdk.java.net/~tvaleev/patches/array_decl_java_base/jdk.patch 
>>
>>
>> I checked the result by eyes thoroughly and did not find anything
>> wrong. So if you're interested I can prepare a patch which covers any
>> full JDK sources or any subset of it.
>> The only questions are which subset should be processed and should I
>> also update copyrights for changed files (doing this automatically
>> could be more risky unless there's
>> already well-tested utility to do this).
>>
> Good to see this. Updating the copyright dates is annoying but if you 
> can do that then it would be good. There is a script to do a bulk 
> update that I think is better for cases like this but it doesn't seem 
> to be run very often these days.
>
> As regards doing the entire source base then I think that would be 
> good. Due to the complexity of testing, changes to the java.desktop 
> module are pushed to jdk/client repo rather than jdk/jdk so if it's 
> not too awkward then it might be helper if the patch for java.desktop 
> were a separate change that gets pushed to jdk/client rather than 
> jdk/jdk.
>
> -Alan

Although cleanup like this is nice, I'll give a word of warning that 
pervasive
changes like that can sometimes cause difficulties when there are lots of
changes in code which is undergoing different lines of development in 
different
branches or repos. If nothing else, I'd consider doing it on a per-component
or per-module basis.

As regards copyrights, there are scripts to fix dates that only modify the
affected files (as compared to what I think Alan is referring to, which is
a script to modify all files in the repo which have been edited that year.)

-- Jon

From mandy.chung at oracle.com  Sat Sep 29 00:35:01 2018
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Sep 2018 17:35:01 -0700
Subject: How can I solve Modularity related issue ?
In-Reply-To: <8632f274-3567-6121-5a60-cf626f8d5c3c@oracle.com>
References: <ef23405648c061fd2db7359c1fa160f1@linux.vnet.ibm.com>
 <8632f274-3567-6121-5a60-cf626f8d5c3c@oracle.com>
Message-ID: <ed754cc4-9be9-c8ca-5ec4-0e9b9a26448a@oracle.com>



On 9/28/18 1:59 AM, Alan Bateman wrote:
> On 28/09/2018 08:28, Ichiroh Takiguchi wrote:
>> Hello.
>>
>> One of JDBC application with JavaDB did not work on JDK12.
>> Following exception happened:
>> ? java.sql.SQLException: No suitable driver found for jdbc:derby:xxxxxx
>>
>> I assume, this issue related Modularity feature...
>> I could not solve this issue by myself.
> I suspect this is related to the de-privileging of the java.sql.rowset 
> module in JDK 9. The java.sql.rowset module is mapped to the platform 
> class loader whereas historically the types in this module were 
> defined by the boot class loader. This is relevant because 
> java.sql.rowset is making use of the java.sql.DriverManager (in the 
> java.sql module) and DriverManager is caller sensitive so it sees the 
> caller coming from java.sql.rowset. This is problematic because the 
> JDBC driver is on the class path and is not visible to the caller's 
> class loader. The visibility check has always been in JDBC and I 
> suspect this usage in the JDBC Rowset implementation only worked by 
> accident in the past because DriverManager used the TCCL when called 
> from code defined to the bootstrap class loader. I'm sure Lance will 
> jump in but all previous investigations into changing behavior going 
> back 20+ has come to nothing due to compatibility concerns.
>

It does look like related to the de-privileging of java.sql.rowset 
module.? JDBC rowset implementation just happened to work in the past as 
it was defined to the bootstrap class loader.

I have created JBS issue for this:
 ?? https://bugs.openjdk.java.net/browse/JDK-8211295

Mandy

From xueming.shen at oracle.com  Sat Sep 29 05:25:42 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 28 Sep 2018 22:25:42 -0700
Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and
 permissions of the files
In-Reply-To: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
References: <d216f3b84891409bb95a44b4d7b61b0d@sap.com>
Message-ID: <5BAF0CD6.90803@oracle.com>

Hi Langer,

Thanks for working on this issue. I will take a look into the 
implementation details
next week. Here are two comments regarding the "direction/approach".

(1) There is a "masked" security concern regarding adding the 
"ownership/permission" into
the jar file.

"Security concern:

The current signed jar spec only protects the name and content of the 
jar entries. If any extra info is added, its value will not be used in 
the signing/verifying process. This means anyone can change these info 
in a signed jar and the user has no way to check if the file is genuine."

This is one of the reasons that it has been debated whether or not it is 
worth the effort to add
these bits, given the permission and ownership are really 
platform/host/config dependent (and
the jars are being downloaded/copied around across the systems with 
various different setup)
and you really need a "root" permission to really take advantage of 
these bits.

(2) Regarding the implementation whats the motivation of use the high 
byte of the "external file
attributes" vs to use the info-zip as suggested in the report? I've not 
looked into zip/unzip
implementation, which one is zip/unzip using?

"A group known as INFO-zip has devised a number of different extensions
for ZIP for Unix. Their first and second extension attempts added
support for UID and GID but not permissions. The third Unix extension,
also known as the "ASi" or "un" extension, provides for file permissions
and symlinks also. These extensions have become de-facto standards,
and have not changed now since 1996."


-Sherman

On 9/25/18, 7:57 AM, Langer, Christoph wrote:
>
> Hi all,
>
> I had asked for opinions regarding adding posix permission support to 
> JDK?s zip handling libraries and tools [1]. Since I didn?t get clear 
> ?no, you can?t do this? answers, I?m now concretely proposing some 
> enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool.
>
> I have reopened the long standing bug report (6194856) which had been 
> set to ?Won?t fix? quite recently for this purpose.
>
> Here are the technical details:
>
> The ZIP format specifications by infozip and pkware ([2] and [3]) do 
> not explicitly specify the handling of posix file permissions. But it 
> seems to be common sense that if file attribute compatibility is set 
> to ?Unix? in the upper byte of CEN field ?version made by?, the file 
> permissions bits are stored in CEN field ?external file attributes?, 
> byte 3 and 4. My changes try to honor this in the least obtrusive way. ??
>
> The following changes are proposed:
>
> java.util.zip.ZipEntry:
>
> it will have an additional field ?posixPerms?. A value of -1 means ?no 
> permission information?, positive values will contain the flag values.
>
> There will be 2 new public methods to read/set the permission information:
>
>                 public Optional<Set<PosixFilePermission>> 
> getPosixPermissions()
>
>                 public void 
> setPosixPermissions(Set<PosixFilePermission> permissions)
>
> The usage of type ?Optional? reflects that posix permissions are not 
> necessarily present in a zip file
>
> java.util.zip.ZipFile:
>
>                 it will have the capability to read the CEN fields and 
> set posixPerms if available
>
> java.util.zip.ZipOutputStream:
>
>                 it will store entries with associated posix 
> permissions as unix type in the CEN, together with the bit mask for 
> the permissions
>
> jdk.jartool:
>
> I propose to add and option "--preserve-posix" or short "-o" to honor 
> the posix bits that may be stored inside zip/jar files. By default the 
> option is not set and hence posix permissions are ignored. If the flag 
> is set and the file system that the jar tool is running on supports 
> posix, posix file permissions that exist in the file system will be 
> stored in newly created/update archives or restored to the file system 
> if such information is present in the archive.
>
> jdk.zipfs:
>
>                 I added the capability for posix file permissions in 
> the implementation. I decided to support PosixFileAttributes by 
> subclassing ZipFileAttributes from this superclass as well as 
> subclassing ZipFileAttributeView from PosixFileAttributeView. However, 
> as PosixFileAttributes also include groups and owners, I would throw 
> UnsupportedOperationExceptions in case of invoking methods to handle 
> these attributes. But this approach seems to be most consistent with 
> e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions.
>
> java.nio.file.attribute.PosixFilePermissions:
>
>                 As this class presents a collection of static helpers, 
> I added definitions for the posix file bit masks together with methods 
> to convert between Sets of PosixFilePermission to bit masks containing 
> the according switches and vice versa. These definitions could 
> theoretically also be moved inside the java.util.zip or jdk.zipfs 
> implementations where they wouldn?t be exposed as public APIs. 
> However, in that case the code would probably need to be duplicated.
>
> I?ve also created two jtreg testcases for both, java.util.zip and 
> jdk.nio.zipfs.
>
> The changes also contain a few further code cleanups.
>
> Here are the links:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6194856
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/6194856.0/>
>
> I?ll write a CSR once there?s some substantial feedback to my endeavor.
>
> Thanks in advance for reviewing/commenting.
>
> Best regards
>
> Christoph
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055375.html
>
> [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip
>
> [3] https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
>


From aph at redhat.com  Sat Sep 29 09:32:35 2018
From: aph at redhat.com (Andrew Haley)
Date: Sat, 29 Sep 2018 10:32:35 +0100
Subject: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not
 return a clean boolean
In-Reply-To: <CA+3eh12A54jjauM4t-iaZ5K53LgFQBPb0bNC2bjmuDcb+QhDfA@mail.gmail.com>
References: <a0bdb334-e04b-9fae-a6a1-4769bac125fb@redhat.com>
 <222e6c1c-b946-7bf7-8eab-08a89622a4f1@oracle.com>
 <97b82f52-59e2-26fe-0d58-0ee4dd6da06f@oracle.com>
 <c7feee67-fd31-9cd4-2057-c1b2f2bd6a2f@redhat.com>
 <6e9e3d5b23eaf7222b4b3c43444fa144@linux.vnet.ibm.com>
 <05d5e185-e415-f4b2-00ba-559f21195c1a@redhat.com>
 <CA+3eh138BFLd4dEOcnnCVtYhOncBeTdNaREPm2DdbY2BTvM3GA@mail.gmail.com>
 <506a7c99-7ac2-6e37-d394-6594acd59346@redhat.com>
 <CA+3eh12A54jjauM4t-iaZ5K53LgFQBPb0bNC2bjmuDcb+QhDfA@mail.gmail.com>
Message-ID: <e6a553ee-e6c0-d0db-8ad2-5cbb45a8d227@redhat.com>

On 09/28/2018 04:08 PM, Volker Simonis wrote:
> Yes, but the next developer who adds a function which returns jboolean
> and looks at your implementation could easily introduce new,  buggy
> code like the one you fixed (because from a C-perspective that makes
> no difference). But if he sees that other JNI functions all return
> exclusively JNI_TRUE/JNI_FALSE he may be  inclined to do so as well.

I'm not convinced that it'll make such mistakes much less likely, and
I do not believe that making code so ugly and verbose is sensible.

Also, I do no believe that we should introduce dead code. And this
absolutely is dead code.

-- 
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 lance.andersen at oracle.com  Sat Sep 29 20:59:18 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 29 Sep 2018 16:59:18 -0400
Subject: RFR 8211295:  DriverManager.getConnection fails when called from
 com.sun.rowset.JdbcRowSetImpl
Message-ID: <BDAF14C6-3892-4B42-9140-B674C28A4F0E@oracle.com>

Attached is the webrev for the JDBC RowSet/DriverManager issue, https://bugs.openjdk.java.net/browse/JDK-8211295 <https://bugs.openjdk.java.net/browse/JDK-8211295>,  that was raised on the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html

I have run the JDBC TestSuite against the Derby Embedded and Derby Network server;  Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql and javax.sql tests.  All pass with the fix

The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ <http://cr.openjdk.java.net/~lancea/8211295/webrev.00/>

Best
Lance

 <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 Alan.Bateman at oracle.com  Sun Sep 30 08:03:26 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 30 Sep 2018 09:03:26 +0100
Subject: RFR 8211295: DriverManager.getConnection fails when called from
 com.sun.rowset.JdbcRowSetImpl
In-Reply-To: <BDAF14C6-3892-4B42-9140-B674C28A4F0E@oracle.com>
References: <BDAF14C6-3892-4B42-9140-B674C28A4F0E@oracle.com>
Message-ID: <48c61772-1692-e067-24f7-294b1afe5761@oracle.com>

On 29/09/2018 21:59, Lance Andersen wrote:
> Attached is the webrev for the JDBC RowSet/DriverManager issue, https://bugs.openjdk.java.net/browse/JDK-8211295 <https://bugs.openjdk.java.net/browse/JDK-8211295>,  that was raised on the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html
>
> I have run the JDBC TestSuite against the Derby Embedded and Derby Network server;  Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql and javax.sql tests.  All pass with the fix
>
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ <http://cr.openjdk.java.net/~lancea/8211295/webrev.00/>
>
This looks okay, I just wonder if there are any other factory or other 
methods that should be exercised in the test to ensure that we have all 
code paths that lead to DriverManager.

-Alan

From Alan.Bateman at oracle.com  Sun Sep 30 15:00:32 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 30 Sep 2018 16:00:32 +0100
Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary
In-Reply-To: <A4D7C24D-98FF-474C-AD4A-46495CCDD815@oracle.com>
References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com>
 <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com>
 <EC7A8505-C791-4175-8EF2-04A0521A8CE1@oracle.com>
 <A4D7C24D-98FF-474C-AD4A-46495CCDD815@oracle.com>
Message-ID: <f3e6993c-7d40-b254-1482-e00c5fcedd7e@oracle.com>

On 27/09/2018 00:38, Igor Ignatyev wrote:
> here is the webrevs w/?JarUtils from default package inserted into 
> jdk.test.lib.util.JarUtils:
> whole patch: 
> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html 
> <http://cr.openjdk.java.net/%7Eiignatyev//8211171/webrev.01/index.html>
>> 655 lines changed: 239 ins; 355 del; 61 mod;
> incremental: 
> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html 
> <http://cr.openjdk.java.net/%7Eiignatyev//8211171/webrev.0-1/index.html>
>> 476 lines changed: 239 ins; 203 del; 34 mod;
>
> doing that, I noticed that both updateJarFile and createJarFile don't 
> close Stream<Path> from Files::find, the current patch fixes that.
>
I see you've also deprecated the String methods in the old class - good! 
I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without 
changing the format but your IDE must be setup differently and it will 
get changed again by whoever next changes it so I think it's okay.

The update to tests using this look fine.

-Alan

From Alan.Bateman at oracle.com  Sun Sep 30 15:31:03 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 30 Sep 2018 16:31:03 +0100
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <df03ca64-d68a-ca8b-5309-395672ac7dcb@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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
Message-ID: <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com>

On 26/09/2018 14:27, Andrew Dinn wrote:
> :
> I'm not clear why we should only use one flag. The two flags I specified
> reflect two independent use cases, one where data stored in an NVM
> device is accessed read-only and another where it is accessed
> read-write. Are you suggesting that the read-only case is redundant? I'm
> not sure I agree. For example, a utility which might want to review the
> state of persistent data while a service is off-line would really want
> to pass flag READ_ONLY_PERSISTENT. Of course, it could employ
> READ_WRITE_PERSISTENT (or equivalently, SYNC) and just not write the
> data but, mutatis mutandis, that same argument would remove the case for
> flag READ_ONLY.
>
I'm wrong on this point. The map takes a single MapMode, not a set of 
modes as I was assuming,? so you are right that it needs two new modes, 
not one. I do think we should re-visit the name though as the native 
flag is MAP_SYNC.

-Alan

From nigro.fra at gmail.com  Fri Sep 28 07:38:48 2018
From: nigro.fra at gmail.com (Francesco Nigro)
Date: Fri, 28 Sep 2018 09:38:48 +0200
Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over
 non-volatile memory
In-Reply-To: <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.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>
 <50ed4716-b76e-6557-1146-03084776c160@redhat.com>
 <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com>
 <ba59cf3a-1b07-1530-79d1-d7f22a1cb900@redhat.com>
 <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com>
 <ad813d34-3ebd-6f66-332a-06b9446367c0@redhat.com>
 <c4fdca2f-7c6a-7429-6b1a-efdff2994bf6@oracle.com>
 <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com>
 <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com>
 <df03ca64-d68a-ca8b-5309-395672ac7dcb@redhat.com>
 <4c8ae5fb-dec1-0685-1b7c-85170d55e6cd@oracle.com>
 <6b29fde7-c147-a346-6bee-c410c57c498d@redhat.com>
 <92bfe8a0-e4d9-a988-387a-fe66b530a260@gmail.com>
 <65f5660a-807b-426a-7af5-d5f95a6089ba@redhat.com>
 <bbeec978-75ea-5fb9-dfc4-aaa35e7ae510@oracle.com>
 <b0ff5779-b9ba-731f-49d7-a920164c5054@gmail.com>
Message-ID: <CAKxGtTWcunzwM=7K21Sk=VKrKfwVzWbAvONBK1nZAYqP-zihsg@mail.gmail.com>

Hi guys!

I'm one of the mentioned devs (like many others) that are using external
(and unsafe) APIs to concurrent access ByteBuffer's content and a developer
of a messaging broker's journal
that would benefit by this JEP :)
Re concurrent access API, how it looks
https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/AtomicBuffer.java
?

note:
I don't know how's considered to appear in these discussions without
presenting myself and I hope to not be OT, but both this JEP and the
comments around are so interesting
that I couldn't resist: I apologize if I'm not respecting some rule on it

Thanks for the hard work,
Francesco

Il giorno ven 28 set 2018 alle ore 09:21 Peter Levart <
peter.levart at gmail.com> ha scritto:

> Hi Stuart,
>
> I mostly agree with your assessment about the suitability of the
> ByteBuffer API for nice multithreaded use. What would such API look like? I
> think pretty much like ByteBuffer but without things that mutate
> mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore.
> That would be in my opinion the most low-level API possible. If you add
> things to such API that coordinate multithreaded access to the underlying
> memory, you are already creating a concurrent data structure for a
> particular set of use cases, which might not cover all possible use cases
> or be sub-optimal at some of them. So I think this is better layered on top
> of such API not built into it. Low-level multithreaded access to memory is,
> in my opinion, always going to be "unsafe" from the standpoint of
> coordination. It's not only the mark/position/limit/ByteOrder that is not
> multithreaded-friendly about ByteBuffer API, but the underlying memory too.
> It would be nice if mark/position/limit/ByteOrder weren't in the way though.
>
> Regards, Peter
>
>
> On 09/28/2018 07:51 AM, Stuart Marks wrote:
>
> Hi Andrew,
>
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think the
> JEP should proceed forward using MBB with the API that you and Alan had
> discussed previously. At most, the discussion of the "right thing" issue
> might affect a side note in the JEP text about possible limitations and
> future directions of this effort. However, it's not a blocker to the JEP
> making progress as far as I'm concerned.
>
> With that in mind, I'll discuss the issue of multithreaded access to
> ByteBuffers and how this bears on whether buffers are or aren't the "right
> answer." There are actually several issues that figure into the "right
> answer" analysis. In this message, though, I'll just focus on the issue of
> multithreaded access.
>
> To recap (possibly for the benefit of other readers) the Buffer class doc
> has the following statement:
>
>     Buffers are not safe for use by multiple concurrent threads. If a
> buffer
>     is to be used by more than one thread then access to the buffer should
> be
>     controlled by appropriate synchronization.
>
> Buffers are primarily designed for sequential operations such as I/O or
> codeset conversion. Typical buffer operations set the mark, position, and
> limit before initiating the operation. If the operation completes partially
> -- not uncommon with I/O or codeset conversion -- the position is updated
> so that the operation can be resumed easily from where it left off.
>
> The fact that buffers not only contain the data being operated upon but
> also mutable state information such as mark/position/limit makes it
> difficult to have multiple threads operate on different parts of the same
> buffer. Each thread would have to lock around setting the position and
> limit and performing the operation, preventing any parallelism. The typical
> way to deal with this is to create multiple buffer slices, one per thread.
> Each slice has its own mark/position/limit values but shares the same
> backing data.
>
> We can avoid the need for this by adding absolute bulk operations, right?
>
> Let's suppose we were to add something like this (considering ByteBuffer
> only, setting the buffer views aside):
>
>     get(int srcOff, byte[] dst, int dstOff, int length)
>     put(int dstOff, byte[] src, int srcOff, int length)
>
> Each thread can perform its operations on a different part of the buffer,
> in parallel, without interference from the others. Presumably these
> operations don't read or write the mark and position. Oh, wait. The
> existing absolute put and get overloads *do* respect the buffer's limit, so
> the absolute bulk operations ought to as well. This means they do depend on
> shared state. (I guess we could make the absolute bulk ops not respect the
> limit, but that seems inconsistent.)
>
> OK, let's adopt an approach similar to what was described by Peter Levart
> a couple messages upthread, where a) there is an initialization step where
> various things including the limit are set properly; b) the buffer is
> published to the worker threads properly, e.g., using a lock or other
> suitable memory operation; and c) all worker threads agree only to use
> absolute operations and to avoid relative operations.
>
> Now suppose the threads have completed their work and you want to, say,
> write the buffer's contents to a channel. You have to carefully make sure
> the threads are all finished and properly publish their results back to
> some central thread, have that central thread receive the results, set the
> position and limit, after which the central thread can initiate the I/O
> operation.
>
> This can certainly be made to work.
>
> But note what we just did. We now have an API where:
>
>  - there are different "phases", where in one phase all the methods work,
> but in another phase only certain methods work (otherwise it breaks
> silently);
>
>  - you have to carefully control all the code to ensure that the wrong
> methods aren't called when the buffer is in the wrong phase (otherwise it
> breaks silently); and
>
>  - you can't hand off the buffer to a library (3rd party or JDK) without
> carefully orchestrating a transition into the right phase (otherwise it
> breaks silently).
>
> Frankly, this is pretty crappy. It's certainly possible to work around it.
> People do, and it is painful, and they complain about it up and down all
> day long (and rightfully so).
>
> Note that this discussion is based primarily on looking at the ByteBuffer
> API. I have not done extensive investigation of the impact of the various
> buffer views (IntBuffer, LongBuffer, etc.), nor have I looked thoroughly at
> the implementations. I have no doubt that we will run into additional
> issues when we do those investigations.
>
> If we were designing an API to support multi-threaded access to memory
> regions, it would almost certainly look nothing like the buffer API. This
> is what Alan means by "buffers might not be the right answer." As things
> stand, it appears quite difficult to me to fix the multi-threaded access
> problem without turning buffers into something they aren't, or fragmenting
> the API in some complex and uncomfortable way.
>
> Finally, note that this is not an argument against adding bulk absolute
> operations! I think we should probably go ahead and do that anyway. But
> let's not fool ourselves into thinking that bulk absolute operations solve
> the multi-threaded buffer access problem.
>
> s'marks
>
>
>